Re: [PATCH 7/8] Revert "ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp"

2017-01-16 Thread Michal Hocko
On Mon 16-01-17 22:01:18, Theodore Ts'o wrote: > On Fri, Jan 06, 2017 at 03:11:06PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because > > sb_getblk_gfp is not really needed as > > sb_getblk > >

Re: Unocorrectable errors with RAID1

2017-01-16 Thread Janos Toth F.
> BTRFS uses a 2 level allocation system. At the higher level, you have > chunks. These are just big blocks of space on the disk that get used for > only one type of lower level allocation (Data, Metadata, or System). Data > chunks are normally 1GB, Metadata 256MB, and System depends on the

Re: [PATCH 7/8] Revert "ext4: avoid deadlocks in the writeback path by using sb_getblk_gfp"

2017-01-16 Thread Theodore Ts'o
On Fri, Jan 06, 2017 at 03:11:06PM +0100, Michal Hocko wrote: > From: Michal Hocko > > This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because > sb_getblk_gfp is not really needed as > sb_getblk > __getblk_gfp > __getblk_slow > grow_buffers >

Re: [PATCH 8/8] Revert "ext4: fix wrong gfp type under transaction"

2017-01-16 Thread Theodore Ts'o
On Fri, Jan 06, 2017 at 03:11:07PM +0100, Michal Hocko wrote: > From: Michal Hocko > > This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that > the transaction context uses memalloc_nofs_save and all allocations > within the this context inherit GFP_NOFS

[PATCH 2/2] btrfs: replace: Use ref counts to avoid destroying target device when canceled

2017-01-16 Thread Qu Wenruo
When dev-replace and scrub are run at the same time, dev-replace can be canceled by scrub. It's quite common for btrfs/069. While in that case, target device can be destroyed at cancel time, leading to a user-after-free bug: Process A (dev-replace) | Process B(scrub)

[PATCH 1/2] btrfs: raid56: Don't keep rbio for later steal

2017-01-16 Thread Qu Wenruo
Before this patch, btrfs raid56 will keep raid56 rbio even all its IO is done. This may save some time allocating rbio, but it can cause deadly use-after-free bug, for the following case: Original fs: 4 devices RAID5 Process A | Process B

Re: Unocorrectable errors with RAID1

2017-01-16 Thread Goldwyn Rodrigues
On 01/16/2017 05:10 AM, Christoph Groth wrote: > Hi, > > I’ve been using a btrfs RAID1 of two hard disks since early 2012 on my > home server. The machine has been working well overall, but recently > some problems with the file system surfaced. Since I do have backups, I > do not worry about

Re: corruption: yet another one after deleting a ro snapshot

2017-01-16 Thread Christoph Anton Mitterer
On Mon, 2017-01-16 at 13:47 +0800, Qu Wenruo wrote: > > > And I highly suspect if the subvolume 6403 is the RO snapshot you > > > just removed. > > > > I guess there is no way to find out whether it was that snapshot, > > is > > there? > > "btrfs subvolume list" could do it." Well that was

Re: [PATCH] btfs-progs: fsck-tests: corrupt nlink value test

2017-01-16 Thread lakshmipathi . g
If btrfs-corrupt-block is in bad shape, then corruption scripts around them won't help in long term. Yes, documentation for btrfs-corrupt-block needs improvement. imo, re-arranged priority will be like : (5), (1)/(3) then (4). Agree that some corner cases, having static image is best

Re: Unocorrectable errors with RAID1

2017-01-16 Thread Austin S. Hemmelgarn
On 2017-01-16 10:42, Christoph Groth wrote: Austin S. Hemmelgarn wrote: On 2017-01-16 06:10, Christoph Groth wrote: root@mim:~# btrfs fi df / Data, RAID1: total=417.00GiB, used=344.62GiB Data, single: total=8.00MiB, used=0.00B System, RAID1: total=40.00MiB, used=68.00KiB System, single:

Re: Unocorrectable errors with RAID1

2017-01-16 Thread Christoph Groth
Austin S. Hemmelgarn wrote: On 2017-01-16 06:10, Christoph Groth wrote: root@mim:~# btrfs fi df / Data, RAID1: total=417.00GiB, used=344.62GiB Data, single: total=8.00MiB, used=0.00B System, RAID1: total=40.00MiB, used=68.00KiB System, single: total=4.00MiB, used=0.00B Metadata, RAID1:

Re: Unocorrectable errors with RAID1

2017-01-16 Thread Austin S. Hemmelgarn
On 2017-01-16 06:10, Christoph Groth wrote: Hi, I’ve been using a btrfs RAID1 of two hard disks since early 2012 on my home server. The machine has been working well overall, but recently some problems with the file system surfaced. Since I do have backups, I do not worry about the data, but

Unocorrectable errors with RAID1

2017-01-16 Thread Christoph Groth
Hi, I’ve been using a btrfs RAID1 of two hard disks since early 2012 on my home server. The machine has been working well overall, but recently some problems with the file system surfaced. Since I do have backups, I do not worry about the data, but I post here to better understand what

Re: corruption: yet another one after deleting a ro snapshot

2017-01-16 Thread Giuseppe Della Bianca
Hi. If it can be helpful. How to double checking the status of my filesystem, I launched ' btrfs scrub / ' and/or ' du -sh /* '. If the file system is corrupt, in my case, the command have aborted. Regards. gdb -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Re: [ISSUE] uncorrectable errors on Raid1

2017-01-16 Thread Duncan
randomtech...@laposte.net posted on Sun, 15 Jan 2017 21:28:01 +0100 as excerpted: > Hello /all, > > I have some concerns about the raid 1 of BTRFS. I have encountered 114 > uncorrectable errors on the directory hosting my 'seafile-data'. Seafile > is a software to backup the data. My 2 hard

[PATCH RFC] btrfs: replace: Use ref counts to avoid destroying target device when canceled

2017-01-16 Thread Qu Wenruo
!!! DON'T MERGE THIS PATCH !!! When dev-replace and scrub are run at the same time, dev-replace can be canceled. It's quite common for btrfs/069. While in that case, target device can be destroyed, leading to a user-after-free bug: Process A (dev-replace) | Process B(scrub)