Re: [PATCH] btrfs: pass correct args to btrfs_async_run_delayed_refs()

hi, On 10/18/2016 06:32 PM, Holger Hoffstätte wrote: On Tue, 18 Oct 2016 15:56:13 +0800, Wang Xiaoguang wrote: In btrfs_truncate_inode_items()->btrfs_async_run_delayed_refs(), we swap the arg2 and arg3 wrongly, fix this. Signed-off-by: Wang Xiaoguang ---

[PATCH v2 1/3] btrfs-progs: send: remove unnecessary code

Some unnecessary codes are deleted. - the setting of subvol is double. - read only check was already done by previous loop. Signed-off-by: Tsutomu Itoh --- v2: description was changed --- cmds-send.c | 11 --- 1 file changed, 11 deletions(-) diff --git

[PATCH 2/3] btrfs-progs: send: fix handling of multiple snapshots (-p option)

We cannot send multiple snapshots at once by -p option. [before] # btrfs send -f /tmp/data0 -p Snap0 Snap[12] At subvol Snap1 At subvol Snap2 ERROR: parent determination failed for 0 # [after] # btrfs send -f /tmp/data0 -p Snap0 Snap[12] At subvol Snap1 At subvol Snap2 # Signed-off-by:

[PATCH 3/3] btrfs-progs: send: fix handling of -c option

When two or more -c options are specified, cannot find a suitable parent. So, output stream is bigger than correct one. [before] # btrfs send -f /tmp/data1 -c Snap0 -c ../SnapX Snap[12] ../SnapY At subvol Snap1 At subvol Snap2 At subvol ../SnapY # ls -l /tmp/data1 -rw--- 1 root root 3153 Oct

[PATCH 1/3] btrfs-progs: send: remove unnecessary code

Some unnecessary codes is deleted. Signed-off-by: Tsutomu Itoh --- cmds-send.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/cmds-send.c b/cmds-send.c index 74d0128..dfdfe01 100644 --- a/cmds-send.c +++ b/cmds-send.c @@ -564,8 +564,6 @@ int cmd_send(int

Re: [PATCH v2 2/3] btrfs-progs: receive: Introduce option to exam and dump send stream

At 10/18/2016 08:07 PM, David Sterba wrote: On Thu, Oct 13, 2016 at 03:32:53PM +0800, Qu Wenruo wrote: Hi David, Any updates? If you're busy on these fix, I could fix these problem and send a new version. I was about to add the series to merge but the output format needs work. At minimum,

Re: bio linked list corruption.

On 10/18/2016 05:10 PM, Linus Torvalds wrote: On Tue, Oct 18, 2016 at 4:42 PM, Chris Mason wrote: Seems to be the whole thing: Ahh. On lkml, so I do have it in my mailbox, but Dave changed the subject line when he tested on ext4 rather than btrfs.. Anyway, the corrupted

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 5:10 PM, Linus Torvalds wrote: > > Adding Andy to the cc, because this *might* be triggered by the > vmalloc stack code itself. Maybe the re-use of stacks showing some > problem? Maybe Chris (who can't see the problem) doesn't have >

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 05:10:56PM -0700, Linus Torvalds wrote: On Tue, Oct 18, 2016 at 4:42 PM, Chris Mason wrote: Seems to be the whole thing: Ahh. On lkml, so I do have it in my mailbox, but Dave changed the subject line when he tested on ext4 rather than btrfs.. Anyway,

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 4:42 PM, Chris Mason wrote: > > Seems to be the whole thing: Ahh. On lkml, so I do have it in my mailbox, but Dave changed the subject line when he tested on ext4 rather than btrfs.. Anyway, the corrupted address is somewhat interesting. As Dave Jones said,

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 04:39:22PM -0700, Linus Torvalds wrote: On Tue, Oct 18, 2016 at 4:31 PM, Chris Mason wrote: Jens, not sure if you saw the whole thread. This has triggered bad page state errors, and also corrupted a btrfs list. It hurts me to say, but it might not

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 4:31 PM, Chris Mason wrote: > > Jens, not sure if you saw the whole thread. This has triggered bad page > state errors, and also corrupted a btrfs list. It hurts me to say, but it > might not actually be your fault. Where is that thread, and what is the

Re: bio linked list corruption.

On 10/18/2016 05:31 PM, Chris Mason wrote: On Tue, Oct 18, 2016 at 05:12:41PM -0600, Jens Axboe wrote: On 10/18/2016 04:42 PM, Dave Jones wrote: So Chris had me do a run on ext4 just for giggles. It took a while, but eventually this fell out... WARNING: CPU: 3 PID: 21324 at

Re: bio linked list corruption.

On Tue, Oct 18, 2016 at 05:12:41PM -0600, Jens Axboe wrote: On 10/18/2016 04:42 PM, Dave Jones wrote: So Chris had me do a run on ext4 just for giggles. It took a while, but eventually this fell out... WARNING: CPU: 3 PID: 21324 at lib/list_debug.c:33 __list_add+0x89/0xb0 list_add corruption.

Re: bio linked list corruption.

On 10/18/2016 04:42 PM, Dave Jones wrote: On Tue, Oct 11, 2016 at 10:45:07AM -0400, Dave Jones wrote: > WARNING: CPU: 1 PID: 3673 at lib/list_debug.c:33 __list_add+0x89/0xb0 > list_add corruption. prev->next should be next (e8806648), but was c967fcd8.

Re: bio linked list corruption.

On Tue, Oct 11, 2016 at 10:45:07AM -0400, Dave Jones wrote: > WARNING: CPU: 1 PID: 3673 at lib/list_debug.c:33 __list_add+0x89/0xb0 > list_add corruption. prev->next should be next (e8806648), but was > c967fcd8. (prev=880503878b80). > CPU: 1 PID: 3673 Comm: trinity-c0

Re: Monitoring Btrfs

I would like to monitor my btrfs-filesystem for missing drives. This is actually correct behavior, the filesystem reports that it should have 6 devices, which is how it knows a device is missing. Missing - means missing at the time of mount. So how are you planning to monitor a disk

Re: question re: trim in btrfs

On 10/18/16 3:06 PM, Tim Walberg wrote: > Forgot to mention - this was on a rather crusty 4.2.6 kernel. Just upgraded > to 4.8.1 > and the issue appears to have been resolved... Thanks for following up. This issue was actually fixed in v4.3. There were a bunch of fixes for discard ranging from

Re: question re: trim in btrfs

Forgot to mention - this was on a rather crusty 4.2.6 kernel. Just upgraded to 4.8.1 and the issue appears to have been resolved... On 10/18/2016 12:42 -0500, Walberg, Tim wrote: >> Unless I'm misinterpreting something it appears that maybe btrfs >> doesn't pass >> fstrim commands

Re: Btrfs dev del

On 2016-10-18 11:02, Stefan Malte Schumacher wrote: Hello One of the drives which I added to my array two days ago was most likely already damaged when I bought it - 312 read errors while scrubbing and lots of SMART errors. I want to take the drive out, go to my hardware vendor and have it

question re: trim in btrfs

Unless I'm misinterpreting something it appears that maybe btrfs doesn't pass fstrim commands down to the underlying drives when being used in a RAID-1 config. I have this output from a small script I wrote to run at boot time (and also via cron.weekly), rather than using continous trim in the

Btrfs dev del

Hello One of the drives which I added to my array two days ago was most likely already damaged when I bought it - 312 read errors while scrubbing and lots of SMART errors. I want to take the drive out, go to my hardware vendor and have it replaced. So I issued the command: "btrfs dev del /dev/sdf

Re: [GIT PULL] Send fix for 4.9

On 10/14/2016 05:54 PM, fdman...@kernel.org wrote: From: Filipe Manana Hi Chris, please pull the following send fix for the 4.9 kernel. Thanks Filipe, I've got this queued up for this week. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs"

Re: Monitoring Btrfs

On 2016-10-17 16:40, Chris Murphy wrote: May be better to use /sys/fs/btrfs//devices to find the device to monitor, and then monitor them with blktrace - maybe there's some courser granularity available there, I'm not sure. The thing is, as far as Btrfs alone is concerned, a drive can be "bad"

Re: Monitoring Btrfs

On 2016-10-17 23:23, Anand Jain wrote: I would like to monitor my btrfs-filesystem for missing drives. This is actually correct behavior, the filesystem reports that it should have 6 devices, which is how it knows a device is missing. Missing - means missing at the time of mount. So how

Re: [PATCH v2 2/3] btrfs-progs: receive: Introduce option to exam and dump send stream

On Thu, Oct 13, 2016 at 03:32:53PM +0800, Qu Wenruo wrote: > Hi David, > > Any updates? > > If you're busy on these fix, I could fix these problem and send a new > version. I was about to add the series to merge but the output format needs work. At minimum, something that's parseable, so some

Re: [PATCH] btrfs: pass correct args to btrfs_async_run_delayed_refs()

On Tue, 18 Oct 2016 15:56:13 +0800, Wang Xiaoguang wrote: > In btrfs_truncate_inode_items()->btrfs_async_run_delayed_refs(), we > swap the arg2 and arg3 wrongly, fix this. > > Signed-off-by: Wang Xiaoguang > --- > fs/btrfs/inode.c | 4 ++-- > 1 file changed, 2

[PATCH] btrfs: pass correct args to btrfs_async_run_delayed_refs()

In btrfs_truncate_inode_items()->btrfs_async_run_delayed_refs(), we swap the arg2 and arg3 wrongly, fix this. Signed-off-by: Wang Xiaoguang --- fs/btrfs/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c

Re: speed up cp --reflink=always

At 10/17/2016 02:50 PM, Stefan Priebe - Profihost AG wrote: Am 17.10.2016 um 03:50 schrieb Qu Wenruo: At 10/17/2016 02:54 AM, Stefan Priebe - Profihost AG wrote: Am 16.10.2016 um 00:37 schrieb Hans van Kranenburg: Hi, On 10/15/2016 10:49 PM, Stefan Priebe - Profihost AG wrote: cp

Re: [PATCH 2/2] man2/ioctl_fideduperange.2: clarify operation some more

Hi Darrick, On 10/18/2016 03:54 AM, Darrick J. Wong wrote: > Clarify the behavior of the dedupe ioctl. Thanks! Applied. Cheers, Michael > Signed-off-by: Darrick J. Wong > --- > man2/ioctl_ficlonerange.2 |2 +- > man2/ioctl_fideduperange.2 | 26

Re: [PATCH 1/2] man2/fallocate.2: document behavior with shared blocks

Hi Darrick, On 10/18/2016 03:54 AM, Darrick J. Wong wrote: > Add a blurb to the fallocate manpage explaining that the fallocate > command with the UNSHARE mode flag may use CoW to unshare blocks to > guarantee that a disk write won't fail with ENOSPC. Thanks! Applied. Cheers, Michael > >