+ for (i = 0; i < BTRFS_SUPER_MIRROR_MAX; i++) {
+ u64 bytenr = btrfs_sb_offset(i);
+
+ ret = btrfs_read_disk_super(bdev, bytenr, &page, &disk_super);
+ if (ret) {
+ if (i == 0)
+ goto error_kfree;
+ /* copy2 is optional */
+
On 28.03.2018 02:39, Anand Jain wrote:
> The only caller btrfs_scan_one_device() sets -EINVAL for error from
> btrfs_read_disk_super(), so this patch returns -EINVAL from the latter
> function.
>
> A preparatory patch to add csum check in btrfs_read_disk_super().
>
> Signed-off-by: Anand Jain
On 28.03.2018 02:39, Anand Jain wrote:
> During the btrfs dev scan make sure that other copies of superblock
> contain the same fsid as the primary SB. So that we bring to the
> user notice if the superblock has been overwritten.
>
> mkfs.btrfs -fq /dev/sdc
> mkfs.btrfs -fq /dev/sdb
> dd if=/
On 28.03.2018 02:39, Anand Jain wrote:
> During the scan context, we aren't verifying the superblock-
> checksum when read.
> This patch fixes it by adding the checksum verification function
> btrfs_check_super_csum() in the function btrfs_read_disk_super().
> And makes device scan to error fail
On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> Test that when we have the no-holes mode enabled and a specific metadata
>> layout, if we punch a hole and fsync the file, at replay time the whole
On Wed, Mar 28, 2018 at 09:48:17AM +0100, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at 3:17 AM, Eryu Guan wrote:
> > On Mon, Mar 26, 2018 at 11:59:21PM +0100, fdman...@kernel.org wrote:
> >> From: Filipe Manana
> >>
> >> Test that when we have the no-holes mode enabled and a specific metadata
>
On Wed, Mar 28, 2018 at 09:45:02AM -0400, Zygo Blaxell wrote:
> On Mon, Mar 19, 2018 at 04:30:17PM +0900, Misono, Tomohiro wrote:
> > This is a part of RFC I sent last December[1] whose aim is to improve
> > normal users' usability.
> > The remaining works of RFC are:
> > - Allow "sub delete" f
On Mon, Mar 19, 2018 at 04:30:17PM +0900, Misono, Tomohiro wrote:
> This is a part of RFC I sent last December[1] whose aim is to improve normal
> users' usability.
> The remaining works of RFC are:
> - Allow "sub delete" for empty subvolume
I don't mean to scope creep on you, but I have a cou
On Tue, Mar 27, 2018 at 07:44:03PM +0200, David Sterba wrote:
> The missing error handling in add_extent_changeset was hidden, so make
> it at least visible in the callers.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c | 19 +++
> 1 file changed, 11 insertions(+),
On Mon, Mar 26, 2018 at 11:59:00PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we have the no-holes mode enabled and fsync a file after punching a
> hole in it, we can end up not logging the whole hole range in the log tree.
> This happens if the file has extent items that sp
On Wed, Mar 28, 2018 at 10:55:56AM +0900, Misono Tomohiro wrote:
> current devel branch of btrfs-progs (github) occasionally fails at misc-test
> 006:
> (kernel is 4.16.0-rc7)
That's strange, the test should be deterministic. There seems to be some
timing involved. I'm able to reproduce here, tha
On Wed, Mar 28, 2018 at 10:55:56AM +0900, Misono Tomohiro wrote:
> current devel branch of btrfs-progs (github) occasionally fails at misc-test
> 006:
> (kernel is 4.16.0-rc7)
Can you please also open an issue on github, with the details attached? Thanks.
--
To unsubscribe from this list: send th
On Wed, Mar 28, 2018 at 02:07:38PM +0800, Lu Fengqi wrote:
> Modify cscope/ctags rule to include directories such as check/
> libbtrfsutil/kernel-lib/kernel-shared.
>
> Signed-off-by: Lu Fengqi
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body
On Wed, Mar 28, 2018 at 02:39:09PM +0800, Qu Wenruo wrote:
> [BUG]
> If we have a symbolic link in rootdir pointing to non-existing location,
> mkfs.btrfs --rootdir will just fail:
> --
> $ mkfs.btrfs -f --rootdir /tmp/rootdir/ /dev/data/btrfs
> btrfs-progs v4.15.1
> See http://btrfs.wiki.kern
Hi btrfs devs,
I recently updated Linux (4.15.x) and rebooted on a machine with a 12x4TB-disk
btrfs volume, and it hung on boot. I did some initial troubleshooting and
eventually saw in `btrfs dev stats` that one disk had a ton of errors. I
settled on a theory that either the disk or the SAS ba
On Tue, Mar 27, 2018 at 08:44:18PM +0800, Qu Wenruo wrote:
> The extent tree of the test fs is like the following:
>
> BTRFS info (device (null)): leaf 16327509003777336587 total ptrs 1 free
> space 3919
> item 0 key (4096 168 4096) itemoff 3944 itemsize 51
> extent refs 1 gen 1 flag
On Tue, Mar 27, 2018 at 08:44:19PM +0800, Qu Wenruo wrote:
> We have several reports about node pointer points to incorrect child
> tree blocks, which could have even wrong owner and level but still with
> valid generation and checksum.
>
> Although btrfs check could handle it and print error mess
When mount fails to read trees like fs tree, checksum tree, extent
tree, etc, there is not enough information about where went wrong.
With this, messages like
"BTRFS warning (device sdf): failed to read root (objectid=7): -5"
would help us a bit.
Signed-off-by: Liu Bo
---
fs/btrfs/disk-io.c |
On Wed, Mar 28, 2018 at 12:40:23PM +0800, Qu Wenruo wrote:
> Basic test case which triggers fsstress with dm-log-writes, and then
> check the fs after each FUA writes.
> With needed infrastructure and special handlers for journal based fs.
>
> Signed-off-by: Qu Wenruo
.
> For xfs:
> _check_xf
On 2018/03/28 23:50, David Sterba wrote:
> On Wed, Mar 28, 2018 at 10:55:56AM +0900, Misono Tomohiro wrote:
>> current devel branch of btrfs-progs (github) occasionally fails at misc-test
>> 006:
>> (kernel is 4.16.0-rc7)
>
> Can you please also open an issue on github, with the details attached?
On 2018年03月28日 23:32, David Sterba wrote:
> On Tue, Mar 27, 2018 at 08:44:18PM +0800, Qu Wenruo wrote:
>> The extent tree of the test fs is like the following:
>>
>> BTRFS info (device (null)): leaf 16327509003777336587 total ptrs 1 free
>> space 3919
>> item 0 key (4096 168 4096) itemoff 394
[BUG]
With latest qgroup metadata reservation patch applied, it's possible to
hit BUG_ON() when running btrfs/042:
--
run fstests btrfs/042 at 2018-03-28 12:14:26
BTRFS: device fsid cc876c27-bf31-44d6-bd6a-2c19b8c8e1b8 devid 1 transid 5
/dev/sdc1
BTRFS info (device sdc1): disk space caching
We have several reports about node pointer points to incorrect child
tree blocks, which could have even wrong owner and level but still with
valid generation and checksum.
Although btrfs check could handle it and print error message like:
leaf parent key incorrect 60670574592
Kernel doesn't have
On 2018年03月28日 22:55, David Sterba wrote:
> On Wed, Mar 28, 2018 at 02:39:09PM +0800, Qu Wenruo wrote:
>> [BUG]
>> If we have a symbolic link in rootdir pointing to non-existing location,
>> mkfs.btrfs --rootdir will just fail:
>> --
>> $ mkfs.btrfs -f --rootdir /tmp/rootdir/ /dev/data/btrfs
Signed-off-by: Qu Wenruo
---
.../016-rootdir-bad-symbolic-link/test.sh | 26 ++
1 file changed, 26 insertions(+)
create mode 100755 tests/mkfs-tests/016-rootdir-bad-symbolic-link/test.sh
diff --git a/tests/mkfs-tests/016-rootdir-bad-symbolic-link/test.sh
b/tests/mk
On Tue, Mar 27, 2018 at 7:13 AM, David Sterba wrote:
> On Mon, Mar 26, 2018 at 10:00:04AM -0500, Ashu Tiwary wrote:
>> It appears my system may have hit the issue reverted here (
>> https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg74621.html
>> ) ( [PATCH] Revert "btrfs: use proper endi
On 29.03.2018 01:11, Liu Bo wrote:
> When mount fails to read trees like fs tree, checksum tree, extent
> tree, etc, there is not enough information about where went wrong.
>
> With this, messages like
>
> "BTRFS warning (device sdf): failed to read root (objectid=7): -5"
>
> would help us a b
27 matches
Mail list logo
