On 06/29/2018 01:28 PM, Marc MERLIN wrote:
On Fri, Jun 29, 2018 at 01:07:20PM +0800, Qu Wenruo wrote:
lowmem repair seems to be going still, but it's been days and -p seems
to do absolutely nothing.
I'm a afraid you hit a bug in lowmem repair code.
By all means, --repair shouldn't really
On 2018年06月29日 13:28, Marc MERLIN wrote:
> On Fri, Jun 29, 2018 at 01:07:20PM +0800, Qu Wenruo wrote:
>>> lowmem repair seems to be going still, but it's been days and -p seems
>>> to do absolutely nothing.
>>
>> I'm a afraid you hit a bug in lowmem repair code.
>> By all means, --repair
On Fri, Jun 29, 2018 at 01:35:06PM +0800, Su Yue wrote:
> > It's hard to estimate, especially when every cross check involves a lot
> > of disk IO.
> >
> > But at least, we could add such indicator to show we're doing something.
> > Maybe we can account all roots in root tree first, before
On 06/29/2018 01:07 PM, Qu Wenruo wrote:
On 2018年06月29日 12:27, Marc MERLIN wrote:
Regular btrfs check --repair has a nice progress option. It wasn't
perfect, but it showed something.
But then it also takes all your memory quicker than the linux kernel can
defend itself and reliably
On Fri, Jun 29, 2018 at 01:07:20PM +0800, Qu Wenruo wrote:
> > lowmem repair seems to be going still, but it's been days and -p seems
> > to do absolutely nothing.
>
> I'm a afraid you hit a bug in lowmem repair code.
> By all means, --repair shouldn't really be used unless you're pretty
> sure
Since commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname for
device list traversal") btrfs_show_devname no longer takes
device_list_mutex. As such the deadlock that 0ccd05285e7f ("btrfs: fix
a possible umount deadlock") aimed to fix no longer exists. So remove
the extra code that commit
On 2018年06月29日 12:27, Marc MERLIN wrote:
> Regular btrfs check --repair has a nice progress option. It wasn't
> perfect, but it showed something.
>
> But then it also takes all your memory quicker than the linux kernel can
> defend itself and reliably completely kills my 32GB server quicker
Regular btrfs check --repair has a nice progress option. It wasn't
perfect, but it showed something.
But then it also takes all your memory quicker than the linux kernel can
defend itself and reliably completely kills my 32GB server quicker than
it can OOM anything.
lowmem repair seems to be
On Thu, Jun 28, 2018 at 3:15 AM, Qu Wenruo wrote:
> I'd like to make sure everyone, including developers and end-users, are
> fine with the restrict error-out behavior.
Yes, please error out, as a start. Requesting this was on my
btrfs-to-do list. A device generation mismatch from a drive
On 2018年06月29日 09:05, Christoph Anton Mitterer wrote:
> Hey Qu and Nikolay.
>
>
> On Thu, 2018-06-28 at 22:58 +0800, Qu Wenruo wrote:
>> Nothing special. Btrfs-progs will handle it pretty well.
> Since this a remote system where the ISP provides only a rescue image
> with pretty old
Hey Qu and Nikolay.
On Thu, 2018-06-28 at 22:58 +0800, Qu Wenruo wrote:
> Nothing special. Btrfs-progs will handle it pretty well.
Since this a remote system where the ISP provides only a rescue image
with pretty old kernel/btrfs-progs, I had to copy a current local
binary and use that... but
On 2018年06月28日 22:36, Adam Borowski wrote:
> On Thu, Jun 28, 2018 at 03:04:43PM +0800, Qu Wenruo wrote:
>> There is a reporter considering btrfs raid1 has a major design flaw
>> which can't handle nodatasum files.
>>
>> Despite his incorrect expectation, btrfs indeed doesn't handle device
>>
On 2018年06月29日 01:10, Andrei Borzenkov wrote:
> 28.06.2018 12:15, Qu Wenruo пишет:
>>
>>
>> On 2018年06月28日 16:16, Andrei Borzenkov wrote:
>>> On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
On 2018年06月28日 11:14, r...@georgianit.com wrote:
>
>
> On Wed, Jun 27, 2018,
Hi Nikolay,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.18-rc2]
[also build test ERROR on next-20180628]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Thu, Jun 28, 2018 at 11:37 AM, Goffredo Baroncelli
wrote:
> Regarding your point 3), it must be point out that in case of NOCOW files,
> even having the same transid it is not enough. It still be possible that a
> copy is update before a power failure preventing the super-block update.
> I
On Thu, Jun 28, 2018 at 9:37 AM, Remi Gauvin wrote:
> On 2018-06-28 10:17 AM, Chris Murphy wrote:
>
>> 2. The new data goes in a single chunk; even if the user does a manual
>> balance (resync) their data isn't replicated. They must know to do a
>> -dconvert balance to replicate the new data.
> Acceptable, but not really apply to software based RAID1.
>
Which completely disregards the minor detail that all the software
Raid's I know of can handle exactly this kind of situation without
loosing or corrupting a single byte of data, (Errors on the remaining
hard drive notwithstanding.)
Hi Nikolay,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.18-rc2]
[also build test ERROR on next-20180628]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi,
Here's my environment:
Linux diablo 4.17.0-gentoo #5 SMP Mon Jun 25 00:26:55 CEST 2018 x86_64
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz GenuineIntel GNU/Linux
btrfs-progs v4.17
Label: 'online' uuid: e4dc6617-b7ed-4dfb-84a6-26e3952c8390
Total devices 2 FS bytes used 3.16TiB
On 28.06.2018 17:17, Christoph Anton Mitterer wrote:
> On Thu, 2018-06-28 at 22:09 +0800, Qu Wenruo wrote:
>>> [ 72.168662] WARNING: CPU: 0 PID: 242 at /build/linux-
>>> uwVqDp/linux-4.16.16/fs/btrfs/ctree.h:1565
>>> btrfs_update_device+0x1b2/0x1c0It
>> looks like it's the old WARN_ON() for
On 2018年06月28日 16:04, Nikolay Borisov wrote:
>
>
> On 28.06.2018 10:04, Qu Wenruo wrote:
>> There is a reporter considering btrfs raid1 has a major design flaw
>> which can't handle nodatasum files.
>>
>> Despite his incorrect expectation, btrfs indeed doesn't handle device
>> generation
On 28.06.2018 11:10, Misono Tomohiro wrote:
> On 2018/06/28 16:12, Qu Wenruo wrote:
>>
>>
>> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>>> On 2018/06/27 17:10, Qu Wenruo wrote:
On 2018年06月26日 14:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit
On Thu, Jun 28, 2018 at 07:22:59PM +0800, Anand Jain wrote:
> The circular locking dependency warning occurs at FSSTRESS_PROG.
> And in particular at doproc() in xfstests/ltp/fsstress.c, randomly
> at any of the command at
> opdesc_tops[] = { ..}
> which involves calling mmap
On Wed, Jun 27, 2018 at 06:19:55PM +0800, Qu Wenruo wrote:
> Commit ff3d27a048d9 ("btrfs: qgroup: Finish rescan when hit the last leaf
> of extent tree") added a new exit for rescan finish.
>
> However after finishing quota rescan, we set
> fs_info->qgroup_rescan_progress to (u64)-1 before we
On 28.06.2018 16:19, Christoph Anton Mitterer wrote:
> Hey.
>
> On a 4.16.16 kernel with a RAID 1 btrfs I got the following messages
> since today.
>
> Data seems still to be readable (correctly)... and there are no other
> errors (like SATA errors) in the kernel log.
>
> Any idea what these
On Wed, Jun 20, 2018 at 07:56:12AM -0700, Chris Mason wrote:
> For COW, btrfs expects pages dirty pages to have been through a few setup
> steps. This includes reserving space for the new block allocations and
> marking
> the range in the state tree for delayed allocation.
>
> A few places
On 28.06.2018 10:04, Qu Wenruo wrote:
> There is a reporter considering btrfs raid1 has a major design flaw
> which can't handle nodatasum files.
>
> Despite his incorrect expectation, btrfs indeed doesn't handle device
> generation mismatch well.
I think this is getting a bit personal, no
Since commit 88c14590cdd6 ("btrfs: use RCU in btrfs_show_devname for
device list traversal") btrfs_show_devname no longer takes
device_list_mutex. As such the deadlock that 0ccd05285e7f ("btrfs: fix
a possible umount deadlock") aimed to fix no longer exists. So remove the
extra code this commit
On 06/28/2018 04:17 PM, Chris Murphy wrote:
> Btrfs does two, maybe three, bad things:
> 1. No automatic resync. This is a net worse behavior than mdadm and
> lvm, putting data at risk.
> 2. The new data goes in a single chunk; even if the user does a manual
> balance (resync) their data isn't
28.06.2018 12:15, Qu Wenruo пишет:
>
>
> On 2018年06月28日 16:16, Andrei Borzenkov wrote:
>> On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月28日 11:14, r...@georgianit.com wrote:
On Wed, Jun 27, 2018, at 10:55 PM, Qu Wenruo wrote:
>
> Please get
On 2018-06-28 10:36 AM, Adam Borowski wrote:
>
> Uhm, that'd be a nasty regression for the regular (no-nodatacow) case.
> The vast majority of data is fine, and extents that have been written to
> while a device is missing will be either placed elsewhere (if the filesystem
> knew it was
On 2018-06-28 10:17 AM, Chris Murphy wrote:
> 2. The new data goes in a single chunk; even if the user does a manual
> balance (resync) their data isn't replicated. They must know to do a
> -dconvert balance to replicate the new data. Again this is a net worse
> behavior than mdadm out of the
On 2018年06月28日 22:17, Christoph Anton Mitterer wrote:
> On Thu, 2018-06-28 at 22:09 +0800, Qu Wenruo wrote:
>>> [ 72.168662] WARNING: CPU: 0 PID: 242 at /build/linux-
>>> uwVqDp/linux-4.16.16/fs/btrfs/ctree.h:1565
>>> btrfs_update_device+0x1b2/0x1c0It
>> looks like it's the old WARN_ON() for
On Wed, Jun 27, 2018 at 08:50:11PM +0200, waxhead wrote:
> Chris Murphy wrote:
> > On Thu, Jun 21, 2018 at 5:13 PM, waxhead wrote:
> > > According to this:
> > >
> > > https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> > > Page 4 , section 1.2
> > >
> > > It claims that BTRFS still
On Thu, Jun 28, 2018 at 03:04:43PM +0800, Qu Wenruo wrote:
> There is a reporter considering btrfs raid1 has a major design flaw
> which can't handle nodatasum files.
>
> Despite his incorrect expectation, btrfs indeed doesn't handle device
> generation mismatch well.
>
> This means if one
On 28/06/2018 09:04, Qu Wenruo wrote:
> Despite his incorrect expectation, btrfs indeed doesn't handle device
> generation mismatch well.
>
> This means if one devices missed and re-appeared, even its generation
> no longer matches with the rest device pool, btrfs does nothing to it,
> but treat
The problems are known with Btrfs raid1, but I think they bear
repeating because they are really not OK.
In the exact same described scenario: a simple clear cut drop off of a
member device, which then later clearly reappears (no transient
failure).
Both mdadm and LVM based raid1 would have
On Thu, 2018-06-28 at 22:09 +0800, Qu Wenruo wrote:
> > [ 72.168662] WARNING: CPU: 0 PID: 242 at /build/linux-
> > uwVqDp/linux-4.16.16/fs/btrfs/ctree.h:1565
> > btrfs_update_device+0x1b2/0x1c0It
> looks like it's the old WARN_ON() for unaligned device size.
> Would you please verify if it is
On 2018年06月28日 21:19, Christoph Anton Mitterer wrote:
> Hey.
>
> On a 4.16.16 kernel with a RAID 1 btrfs I got the following messages
> since today.
>
> Data seems still to be readable (correctly)... and there are no other
> errors (like SATA errors) in the kernel log.
>
> Any idea what these
On 2018年06月28日 21:26, Anand Jain wrote:
>
>
> On 06/28/2018 04:02 PM, Qu Wenruo wrote:
>> Also CC Anand Jain, since he is also working on various device related
>> work, and an expert on this.
>>
>> Especially I'm not pretty sure if such enhancement is already on his
>> agenda or there are
On 06/28/2018 04:02 PM, Qu Wenruo wrote:
Also CC Anand Jain, since he is also working on various device related
work, and an expert on this.
Especially I'm not pretty sure if such enhancement is already on his
agenda or there are already some unmerged patch for this.
Right, some of the
On 06/28/2018 09:42 AM, Remi Gauvin wrote:
There seems to be a major design flaw with BTRFS that needs to be better
documented, to avoid massive data loss.
Tested with Raid 1 on Ubuntu Kernel 4.15
The use case being tested was a Virtualbox VDI file created with
NODATACOW attribute, (as is
Hey.
On a 4.16.16 kernel with a RAID 1 btrfs I got the following messages
since today.
Data seems still to be readable (correctly)... and there are no other
errors (like SATA errors) in the kernel log.
Any idea what these could mean?
Thanks,
Chris.
[ 72.168662] WARNING: CPU: 0 PID: 242 at
On 2018-06-28 07:46, Qu Wenruo wrote:
On 2018年06月28日 19:12, Austin S. Hemmelgarn wrote:
On 2018-06-28 05:15, Qu Wenruo wrote:
On 2018年06月28日 16:16, Andrei Borzenkov wrote:
On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo
wrote:
On 2018年06月28日 11:14, r...@georgianit.com wrote:
On Wed, Jun
On 2018年06月28日 19:12, Austin S. Hemmelgarn wrote:
> On 2018-06-28 05:15, Qu Wenruo wrote:
>>
>>
>> On 2018年06月28日 16:16, Andrei Borzenkov wrote:
>>> On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo
>>> wrote:
On 2018年06月28日 11:14, r...@georgianit.com wrote:
>
>
> On Wed,
On 06/12/2018 12:16 AM, David Sterba wrote:
On Mon, Jun 11, 2018 at 10:50:54AM +0100, Filipe Manana wrote:
btrfs: replace uuid_mutex by device_list_mutex in
btrfs_open_devices
*
* the mutex can be very coarse and can cover long-running operations
*
* protects: updates
On 2018-06-28 05:15, Qu Wenruo wrote:
On 2018年06月28日 16:16, Andrei Borzenkov wrote:
On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
On 2018年06月28日 11:14, r...@georgianit.com wrote:
On Wed, Jun 27, 2018, at 10:55 PM, Qu Wenruo wrote:
Please get yourself clear of what other raid1 is
On 2018年06月28日 16:16, Andrei Borzenkov wrote:
> On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
>>
>>
>> On 2018年06月28日 11:14, r...@georgianit.com wrote:
>>>
>>>
>>> On Wed, Jun 27, 2018, at 10:55 PM, Qu Wenruo wrote:
>>>
Please get yourself clear of what other raid1 is doing.
>>>
On Thu, Jun 28, 2018 at 11:16 AM, Andrei Borzenkov wrote:
> On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
>>
>>
>> On 2018年06月28日 11:14, r...@georgianit.com wrote:
>>>
>>>
>>> On Wed, Jun 27, 2018, at 10:55 PM, Qu Wenruo wrote:
>>>
Please get yourself clear of what other raid1 is
On Thu, Jun 28, 2018 at 8:39 AM, Qu Wenruo wrote:
>
>
> On 2018年06月28日 11:14, r...@georgianit.com wrote:
>>
>>
>> On Wed, Jun 27, 2018, at 10:55 PM, Qu Wenruo wrote:
>>
>>>
>>> Please get yourself clear of what other raid1 is doing.
>>
>> A drive failure, where the drive is still there when the
On 2018/06/28 16:12, Qu Wenruo wrote:
>
>
> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>> On 2018/06/27 17:10, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
Hello Nikolay,
I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota
Also CC Anand Jain, since he is also working on various device related
work, and an expert on this.
Especially I'm not pretty sure if such enhancement is already on his
agenda or there are already some unmerged patch for this.
Thanks,
Qu
On 2018年06月28日 15:04, Qu Wenruo wrote:
> There is a
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Qu Wenruo
> Sent: Thursday, 28 June 2018 5:16 PM
> To: Nikolay Borisov ; Qu Wenruo ;
> linux-btrfs@vger.kernel.org
> Subject: Re: [PATCH RFC] btrfs: Do extra device generation check at mount
On 2018年06月28日 15:17, Su Yue wrote:
>
>
> On 06/28/2018 03:04 PM, Qu Wenruo wrote:
>> There is a reporter considering btrfs raid1 has a major design flaw
>> which can't handle nodatasum files.
>>
>> Despite his incorrect expectation, btrfs indeed doesn't handle device
>> generation mismatch
On 2018年06月28日 15:06, Nikolay Borisov wrote:
>
>
> On 28.06.2018 10:04, Qu Wenruo wrote:
>> There is a reporter considering btrfs raid1 has a major design flaw
>> which can't handle nodatasum files.
>>
>> Despite his incorrect expectation, btrfs indeed doesn't handle device
>> generation
On 2018年06月27日 16:25, Misono Tomohiro wrote:
> On 2018/06/27 17:10, Qu Wenruo wrote:
>>
>>
>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>>> Hello Nikolay,
>>>
>>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>>> on quota enable to btrfs_quota_enable") in 4.17 sometimes
On 06/28/2018 03:04 PM, Qu Wenruo wrote:
There is a reporter considering btrfs raid1 has a major design flaw
which can't handle nodatasum files.
Despite his incorrect expectation, btrfs indeed doesn't handle device
generation mismatch well.
Just say " btrfs indeed doesn't handle device
On 28.06.2018 10:04, Qu Wenruo wrote:
> There is a reporter considering btrfs raid1 has a major design flaw
> which can't handle nodatasum files.
>
> Despite his incorrect expectation, btrfs indeed doesn't handle device
> generation mismatch well.
>
> This means if one devices missed and
There is a reporter considering btrfs raid1 has a major design flaw
which can't handle nodatasum files.
Despite his incorrect expectation, btrfs indeed doesn't handle device
generation mismatch well.
This means if one devices missed and re-appeared, even its generation
no longer matches with the
On 28.06.2018 08:34, Eryu Guan wrote:
> On Thu, Jun 28, 2018 at 08:11:00AM +0300, Nikolay Borisov wrote:
>>
>>
>> On 1.06.2018 04:34, Qu Wenruo wrote:
>>> This is a long existing bug (from 2012) but exposed by a reporter
>>> recently, that when compressed extent without data csum get written
60 matches
Mail list logo
