interrupt btrfs filesystem defragment -r /

[David Arendt]

Hi,

Is it safe to interrupt a btrfs filesystem defrag -r / by using ctrl-c
or should it be avoided ?

Thanks in advance,

David Arendt

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

[David Arendt]

Hi,

unfortunately I did not dump meminfo before the crash.

Here is the actual meminfo as of now with the copy running for about 3
hours.

MemTotal:   32806572 kB
MemFree:  197336 kB
MemAvailable:   31226888 kB
Buffers:  52 kB
Cached: 30603160 kB
SwapCached:11880 kB
Active: 29015008 kB
Inactive:2017292 kB
Active(anon): 162124 kB
Inactive(anon):   285104 kB
Active(file):   28852884 kB
Inactive(file):  1732188 kB
Unevictable:7092 kB
Mlocked:7092 kB
SwapTotal:  62522692 kB
SwapFree:   62460464 kB
Dirty:231944 kB
Writeback: 0 kB
AnonPages:425160 kB
Mapped:   227656 kB
Shmem: 12160 kB
Slab:1380280 kB
SReclaimable: 774584 kB
SUnreclaim:   605696 kB
KernelStack:7840 kB
PageTables:12800 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:78925976 kB
Committed_AS:1883256 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:20220592 kB
DirectMap2M:13238272 kB
DirectMap1G: 1048576 kB

I will write a cronjob that dumps meminfo every 5 minutes to a file, so
I will have more info on the next crash.

The crash is not an isolated one as I already had this crash multiple
times with -rc7 and -rc8. It seems only to occur when copying from
7200rpm harddisks to 5600rpm ones, and never when copying between two
7200rpm or two 5400rpm.

Thanks,
David Arendt

On 12/13/2016 08:55 PM, Xin Zhou wrote:
> Hi David,
>
> It has GFP_NOFS flags, according to definition,
> the issue might have happened during initial DISK/IO.
>
> By the way, did you get a chance to dump the meminfo and run "top" before the 
> system hang?
> It seems more info about the system running state needed to know the issue. 
> Thanks.
>
> Xin
>
>  
>
> Sent: Tuesday, December 13, 2016 at 9:11 AM
> From: "David Arendt" <ad...@prnet.org>
> To: linux-btrfs@vger.kernel.org, linux-ker...@vger.kernel.org
> Subject: page allocation stall in kernel 4.9 when copying files from one 
> btrfs hdd to another
> Hi,
>
> I receive the following page allocation stall while copying lots of
> large files from one btrfs hdd to another.
>
> Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for
> 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL)
> Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959 Comm: kworker/u16:8
> Tainted: P O 4.9.0 #1
> Dec 13 13:04:29 server kernel: Hardware name: ASUS All Series/H87M-PRO,
> BIOS 2102 10/28/2014
> Dec 13 13:04:29 server kernel: Workqueue: btrfs-extent-refs
> btrfs_extent_refs_helper
> Dec 13 13:04:29 server kernel:  813f3a59
> 81976b28 c90011093750
> Dec 13 13:04:29 server kernel: 81114fc1 02400840f39b6bc0
> 81976b28 c900110936f8
> Dec 13 13:04:29 server kernel: 88070010 c90011093760
> c90011093710 02400840
> Dec 13 13:04:29 server kernel: Call Trace:
> Dec 13 13:04:29 server kernel: [] ? dump_stack+0x46/0x5d
> Dec 13 13:04:29 server kernel: [] ?
> warn_alloc+0x111/0x130
> Dec 13 13:04:33 server kernel: [] ?
> __alloc_pages_nodemask+0xbe8/0xd30
> Dec 13 13:04:33 server kernel: [] ?
> pagecache_get_page+0xe4/0x230
> Dec 13 13:04:33 server kernel: [] ?
> alloc_extent_buffer+0x10b/0x400
> Dec 13 13:04:33 server kernel: [] ?
> btrfs_alloc_tree_block+0x125/0x560
> Dec 13 13:04:33 server kernel: [] ?
> read_extent_buffer_pages+0x21f/0x280
> Dec 13 13:04:33 server kernel: [] ?
> __btrfs_cow_block+0x141/0x580
> Dec 13 13:04:33 server kernel: [] ?
> btrfs_cow_block+0x100/0x150
> Dec 13 13:04:33 server kernel: [] ?
> btrfs_search_slot+0x1e9/0x9c0
> Dec 13 13:04:33 server kernel: [] ?
> __set_extent_bit+0x512/0x550
> Dec 13 13:04:33 server kernel: [] ?
> lookup_inline_extent_backref+0xf5/0x5e0
> Dec 13 13:04:34 server kernel: [] ?
> set_extent_bit+0x24/0x30
> Dec 13 13:04:34 server kernel: [] ?
> update_block_group.isra.34+0x114/0x380
> Dec 13 13:04:34 server kernel: [] ?
> __btrfs_free_extent.isra.35+0xf4/0xd20
> Dec 13 13:04:34 server kernel: [] ?
> btrfs_merge_delayed_refs+0x61/0x5d0
> Dec 13 13:04:34 server kernel: [] ?
> __btrfs_run_delayed_refs+0x902/0x10a0
> Dec 13 13:04:34 server kernel: [] ?
> btrfs_run_delayed_refs+0x90/0x2a0
> Dec 13 13:04:34 server kernel: [] ?
> delayed_ref_async_start+0x84/0xa0
> Dec 13 13:04:34 server kernel: [] ?
> process_one_work+0x11d/0x3b0
> Dec 13 13:04:34 server kernel: [] ?
> worker_thread+0x42/0x4b0
> Dec 13 13:04:34 se

page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

[David Arendt]

Dec 13 13:04:34 server kernel: Swap cache stats: add 60282, delete
60213, find 249865/258319
Dec 13 13:04:34 server kernel: Free swap  = 62482976kB
Dec 13 13:04:34 server kernel: Total swap = 62522692kB
Dec 13 13:04:34 server kernel: 8364614 pages RAM
Dec 13 13:04:34 server kernel: 0 pages HighMem/MovableOnly
Dec 13 13:04:34 server kernel: 162971 pages reserved

Has anyone any idea what could go wrong here ?

Thanks in advance,

David Arendt

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs random filesystem corruption in kernel 3.17

[David Arendt]

]  [8113abb5] ? __inode_wait_for_writeback+0x65/0xb0
[   55.479591]  [810a8f70] ? wake_atomic_t_function+0x30/0x30
[   55.479592]  [8112f276] ? evict+0xa6/0x160
[   55.479594]  [812e2c2d] ? btrfs_orphan_cleanup+0x1ed/0x430
[   55.479595]  [812e31c8] ? btrfs_lookup_dentry+0x358/0x4c0
[   55.479596]  [812e3339] ? btrfs_lookup+0x9/0x30
[   55.479598]  [8111f6c4] ? lookup_real+0x14/0x50
[   55.479599]  [81120292] ? __lookup_hash+0x32/0x50
[   55.479600]  [81120938] ? lookup_slow+0x48/0xc0
[   55.479601]  [811227bc] ? path_lookupat+0x73c/0x770
[   55.479603]  [81164860] ? posix_acl_xattr_get+0x40/0xb0
[   55.479605]  [81137a80] ? generic_getxattr+0x50/0x80
[   55.479606]  [8112281e] ? filename_lookup.isra.51+0x2e/0x90
[   55.479607]  [8112553f] ? user_path_at_empty+0x5f/0xb0
[   55.479608]  [81125549] ? user_path_at_empty+0x69/0xb0
[   55.479609]  [8111b690] ? vfs_fstatat+0x40/0x90
[   55.479610]  [8111b862] ? SyS_newlstat+0x12/0x30
[   55.479611]  [8111f89d] ? path_put+0xd/0x20
[   55.479613]  [81138ab7] ? SyS_getxattr+0x57/0x80
[   55.479614]  [817053d2] ? system_call_fastpath+0x16/0x1b
[   55.479615] ---[ end trace a8ad56fd476f7475 ]---
[   55.479620] BTRFS error (device sda2): Error removing orphan entry, 
stopping orphan cleanup

[   55.479621] BTRFS critical (device sda2): could not do orphan cleanup -22
[   83.454294] parent transid verify failed on 51150848 wanted 272368 
found 276401
[   83.454945] parent transid verify failed on 918274048 wanted 273135 
found 274590
[   83.455601] parent transid verify failed on 508444672 wanted 274054 
found 276617
[   83.456251] parent transid verify failed on 18317623296 wanted 275876 
found 278431
[   83.456897] parent transid verify failed on 127254528 wanted 276488 
found 276490
[   84.647964] parent transid verify failed on 51150848 wanted 272368 
found 276401
[   84.648612] parent transid verify failed on 918274048 wanted 273135 
found 274590
[   84.649267] parent transid verify failed on 508444672 wanted 274054 
found 276617
[   84.649913] parent transid verify failed on 18317623296 wanted 275876 
found 278431
[   84.650557] parent transid verify failed on 127254528 wanted 276488 
found 276490



On 10/14/14 12:36 AM, Duncan wrote:

Rich Freeman posted on Mon, 13 Oct 2014 16:42:14 -0400 as excerpted:


On Mon, Oct 13, 2014 at 4:27 PM, David Arendt ad...@prnet.org wrote:

 From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least related to snapshots, therefore I decided to post using
another subject to draw attention from people not concerned about btrfs
send to it. More information can be found in the brtfs send posts.

Did the filesystem you tried to balance contain snapshots ? Read only
ones ?

The filesystem contains numerous subvolumes and snapshots, many of which
are read-only.  I'm managing many with snapper.

The similarity of the transid verify errors made me think this issue is
related, and the root cause may have nothing to do with btrfs send.

As far as I can tell these errors aren't having any affect on my data -
hopefully the system is catching the problems before there are actual
disk writes/etc.

Summarizing what I've seen on the threads...

1) The bug seems to be read-only snapshot related.  The connection to
send is that send creates read-only snapshots, but people creating read-
only snapshots for other purposes are now reporting the same problem, so
it's not send, it's the read-only snapshots.

2) Writable snapshots haven't been implicated yet, and the working set
from which the snapshots are taken doesn't seem to be affected, either.
So in that sense it's not affecting ordinary usage, only the read-only
snapshots themselves.

3) More problematic, however, is the fact that these apparently corrupted
read-only snapshots often are not listed properly and can't be deleted,
tho I'm not sure if that's /all/ the corrupted snapshots or only part of
them. So while it may not affect ordinary operation in the short term,
over time until there's a fix, people routinely doing read-only snapshots
are going to be getting more and more of these undeletable snapshots, and
depending on whether the eventual patch only prevents more or can
actually fix the bad ones (possibly via btrfs check or the like),
affected filesystems may ultimately have to be blown away and recreated
with a fresh mkfs, in ordered to kill the currently undeletable snapshots.

So the first thing to do would be to shut off whatever's making read-only
snapshots, so you don't make the problem worse while it's being
investigated.  For those who can do that without too big an interruption
to their normal routine (who don't depend on send/receive, for instance),
just keep it off for the time being.  For those who depend on read-only
snapshots (send

Re: Random file system corruption in 3.17 (not BTRFS related...?)

[David Arendt]

I didn't notice a corruption on other filesystems with kernel 3.17.0. 
Also I didn't experience any hangs except when trying to mount a 
corrupted btrfs but this was causing a hang within less than 10 seconds. 
It could be that your problem is unrelated and that the corruption you 
are experiencing is due to an unrelated hang followed by a hard 
powerdown. Have you been able to capture any btrfs related kernel panics ?


On 10/14/14 6:54 PM, Robert White wrote:

Howdy,

So I run several gentoo systems and I upgraded two of them to kernel 
3.17.0


One using BTRFS for root.
One using ext3 for root (via the ext4 driver)

_Both_ systems exhibited strange behavior (long pauses and then hangs 
requiring hard-power) within several hours. Both then had random 
filesystem damage.


On the BTRFS system much of my browser settings for firefox were 
trashed, particularly the cookies and saved conifigurations for 
add-ons (like which sites had scripts enabled/disabled in no-script) etc.


On the ext3/4 system there were several corruptions including a 
pipe/special file with a large non-zero size that required I do a 
fsck -fyD /dev/sda3 to repair. (one comment from fsck was that the 
pipe/special file looked like a directory or some such)


So I can say that corruption is taking place, but I suspect it is 
_not_ happening in the BTRFS specific code.


(ASIDE: both systems are older amd64 using built-in radeon display 
hardware.)


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

On 10/13/2014 02:40 PM, john terragon wrote:
 Actually it seems strange that a send operation could corrupt the
 source subvolume or fs. Why would the send modify the source subvolume
 in any significant way? The only way I can find to reconcile your
 observations with mine is that maybe the snapshots get corrupted not
 by the send operation by itself but when they are generated with -r
 (readonly, as it is needed to send them). Are the corrupted snapshots
 you have in machine 2 (the one in which send was never used) readonly?
Yes, on both machines there are only readonly snapshots.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs random filesystem corruption in kernel 3.17

[David Arendt]

From my own experience and based on what other people are saying, I
think there is a random btrfs filesystem corruption problem in kernel
3.17 at least related to snapshots, therefore I decided to post using
another subject to draw attention from people not concerned about btrfs
send to it. More information can be found in the brtfs send posts.

Did the filesystem you tried to balance contain snapshots ? Read only ones ?

On 10/13/2014 07:22 PM, Rich Freeman wrote:
 On Sun, Oct 12, 2014 at 7:11 AM, David Arendt ad...@prnet.org wrote:
 This weekend I finally had time to try btrfs send again on the newly
 created fs. Now I am running into another problem:

 btrfs send returns: ERROR: send ioctl failed with -12: Cannot allocate
 memory

 In dmesg I see only the following output:

 parent transid verify failed on 21325004800 wanted 2620 found 8325

 I'm not using send at all, but I've been running into parent transid
 verify failed messages where the wanted is way smaller than the found
 when trying to balance a raid1 after adding a new drive.  Originally I
 had gotten a BUG, and after reboot the drive finished balancing
 (interestingly enough without moving any chunks to the new drive -
 just consolidating everything on the old drives), and then when I try
 to do another balance I get:
 [ 4426.987177] BTRFS info (device sdc2): relocating block group
 10367073779712 flags 17
 [ 4446.287998] BTRFS info (device sdc2): found 13 extents
 [ 4451.330887] parent transid verify failed on 10063286579200 wanted
 987432 found 993678
 [ 4451.350663] parent transid verify failed on 10063286579200 wanted
 987432 found 993678

 The btrfs program itself outputs:
 btrfs balance start -v /data
 Dumping filters: flags 0x7, state 0x0, force is off
   DATA (flags 0x0): balancing
   METADATA (flags 0x0): balancing
   SYSTEM (flags 0x0): balancing
 ERROR: error during balancing '/data' - Cannot allocate memory
 There may be more info in syslog - try dmesg | tail

 This is also on 3.17.  This may be completely unrelated, but it seemed
 similar enough to be worth mentioning.

 The filesystem otherwise seems to work fine, other than the new drive
 not having any data on it:
 Label: 'datafs'  uuid: cd074207-9bc3-402d-bee8-6a8c77d56959
 Total devices 6 FS bytes used 2.16TiB
 devid1 size 2.73TiB used 2.40TiB path /dev/sdc2
 devid2 size 931.32GiB used 695.03GiB path /dev/sda2
 devid3 size 931.32GiB used 700.00GiB path /dev/sdb2
 devid4 size 931.32GiB used 700.00GiB path /dev/sdd2
 devid5 size 931.32GiB used 699.00GiB path /dev/sde2
 devid6 size 2.73TiB used 0.00 path /dev/sdf2

 This is btrfs-progs-3.16.2.

 --
 Rich

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs random filesystem corruption in kernel 3.17

[David Arendt]

As these to machines are running as server for different purposes (yes,
I know that btrfs is unstable and any corruption or data loss is at my
own risk therefore I have good backups), I want to reboot them not more
then necessary.

However I tried to bring my reboot times in relation with corruptions:

machine 1:

d? ? ?  ? ?? root.20141009.000503.backup

reboot   system boot  3.17.0   Thu Oct  9 23:20   still running
reboot   system boot  3.17.0   Tue Oct  7 21:25 - 23:18 (2+01:53)
reboot   system boot  3.17.0   Mon Oct  6 22:47 - 23:18 (3+00:31)

For this machine, corruption seems to have occurred for a snapshot
created after a reboot.


machine 2:

d? ? ??  ?? root.20141006.003239.backup
d? ? ??  ?? root.20141007.001616.backup
d? ? ??  ?? root.20141008.000501.backup
d? ? ??  ?? root.20141009.052436.backup

reboot   system boot  3.17.0   Thu Oct  9 21:31   still running
reboot   system boot  3.17.0   Tue Oct  7 21:27 - 21:30 (2+00:03)
reboot   system boot  3.17.0   Tue Oct  7 17:51 - 21:26  (03:34)
reboot   system boot  3.17.0   Sun Oct  5 23:50 - 17:50 (1+17:59)
reboot   system boot  3.17.0   Sun Oct  5 23:47 - 23:49  (00:01)

During the next days, I will setup a virtual machine to do more tests.

On 10/13/2014 10:48 PM, john terragon wrote:
 I think I just found a consistent simple way to trigger the problem
 (at least on my system). And, as I guessed before, it seems to be
 related just to readonly snapshots:

 1) I create a readonly snapshot
 2) I do some changes on the source subvolume for the snapshot (I'm not
 sure changes are strictly needed)
 3) reboot (or probably just unmount and remount. I reboot because the
 fs I've problems with contains my root subvolume)

 After the rebooting (or the remount) I consistently have the corruption
 with the usual multitude of these in dmesg
 parent transid verify failed on 902316032 wanted 2484 found 4101
 and the characteristic ls -la output

 drwxr-xr-x 1 root root  250 Oct 10 15:37 root
 d? ? ??   ?? root-b2
 drwxr-xr-x 1 root root  250 Oct 10 15:37 root-b3
 d? ? ??   ?? root-backup

 root-backup and root-b2 are both readonly whereas root-b3 is rw (and
 it didn't get corrupted).

 David, maybe you can try the same steps on one of your machines?

 John

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs random filesystem corruption in kernel 3.17

[David Arendt]

I'm also using no compression.

On 10/13/2014 11:22 PM, john terragon wrote:
 I'm using compress=no so compression doesn't seem to be related, at
 least in my case. Just read-only snapshots on 3.17 (although I haven't
 tried 3.16).

 John

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

This weekend I finally had time to try btrfs send again on the newly
created fs. Now I am running into another problem:

btrfs send returns: ERROR: send ioctl failed with -12: Cannot allocate
memory

In dmesg I see only the following output:

parent transid verify failed on 21325004800 wanted 2620 found 8325


On 10/07/2014 10:46 PM, Chris Mason wrote:
 On Tue, Oct 7, 2014 at 4:45 PM, David Arendt ad...@prnet.org wrote:
 On 10/07/2014 03:19 PM, Chris Mason wrote:


  On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
  I did a revert of this commit. After creating a snapshot, the
  filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
  seconds after mount without error message) . Maybe there was some
  previous damage that just appeared now. This evening, I will restore
  from backup and report back.

  On October 7, 2014 12:22:11 AM CEST, Chris Mason c...@fb.com wrote:
  On Mon, Oct 6, 2014 at 4:51 PM, David Arendt ad...@prnet.org
 wrote:
   I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
   working without any problem. Afterwards I upgraded again to
 3.17 and
   the
   problem reappeared. So the problem seems to be kernel version
  related.

  [ backref errors during btrfs-send ]

  Ok then, our list of suspects is pretty short.  Can you easily build
  test kernels?

  I'd like to try reverting this commit:

  51f395ad4058883e4273b02fdebe98072dbdc0d2

  Oh no!  Reverting this definitely should not have caused corruptions,
  so I think the problem was already there.  Do you still have the
  filesystem image?

  Please let us know if you're missing files off the backup, we'll help
  pull them out.

 Due to space constraints, it was not possible to take an image of the
 corrupted filesystem. As I do backups daily, and the problems occurred 5
 hours after backup, no file was lost. Thanks for offering your help. In
 4 days I will do some send tests on the newly created filesystem and
 report back.

 Ok, if you have the kernel messages from the panic, please send them
 along.

 -chris



 -- 
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

Just to let you know, I just tried an ls -l on 2 machines running kernel
3.17 and btrfs-progs 3.16.2.

Here is my ls -l output:

Machine 1:
ls: cannot access root.20141009.000503.backup: Cannot allocate memory
total 0
d? ? ?  ? ?? root.20141009.000503.backup
drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141012.095526.backup
drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141012.000503.backup
drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141011.000502.backup
drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141010.000502.backup

root.20141009.000503.backup is not deletable.

Machine 2:
ls: cannot access root.20141006.003239.backup: Cannot allocate memory
ls: cannot access root.20141007.001616.backup: Cannot allocate memory
ls: cannot access root.20141008.000501.backup: Cannot allocate memory
ls: cannot access root.20141009.052436.backup: Cannot allocate memory
total 0
d? ? ??  ?? root.20141009.052436.backup
d? ? ??  ?? root.20141008.000501.backup
d? ? ??  ?? root.20141007.001616.backup
d? ? ??  ?? root.20141006.003239.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140925.001125.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140924.001017.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140923.001008.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140922.001836.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140921.001029.backup
drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140920.001020.backup

The ? ones are also not deletable.

Both machines are giving transid verify failed errors.

I verified my logfiles and this problem was never there using previous
kernel versions. On machine 1, it is also sure that it was not any
previous corruption as this filesystem has also been created with
btrfs-progs 3.16.2 using kernel 3.17.

On 10/12/2014 05:24 PM, john terragon wrote:
 Hi.

 I just wanted to confirm David's story so to speak :)

 -kernel 3.17-rc7 (didn't bother to compile 3.17 as there weren't any
 btrfs fixes, I think)

 -btrfs-progs 3.16.2 (also compiled from source, so no
 distribution-specific patches)

 -fresh fs

 -I get the same two errors David got (first I got the I/O error one
 and then the memory allocation one)

 -plus now when I ls -la the fs top volume this is what I get

 drwxrwsr-x 1 root staff  30 Sep 11 16:15 home
 d? ? ??   ?? home-backup
 drwxr-xr-x 1 root root  250 Oct 10 15:37 root
 d? ? ??   ?? root-backup
 drwxr-xr-x 1 root root   88 Sep 15 16:02 vms
 drwxr-xr-x 1 root root   88 Sep 15 16:02 vms-backup

 yes, the question marks on those two *-backup snapshots are really
 there. I can't access the snapshots, I can't delete them, I can't do
 anything with them.

 -btrfs check segfaults

 -the events that led to this situation are these:
  1) btrfs su snap -r root root-backup
  2) send |receive (the entire root-backup, not and incremental send)
  immediate I/O error
  3) move on to home: btrfs su snap -r home home-backup
  4) send|receive (again not an incremental send)
  everything goes well (!)
  5) retry with root: btrfs su snap -r root root-backup
  6) send|receive
  and it goes seemingly well
  7) apt-get dist-upgrade just to modify root and try an incremental send
  8) reboot after the dist-upgrade
  9) ls -la the fs top volume: first I get the memory allocation error
 and after that
any ls -la gives the output I pasted above. (notice that beside
 the ls -la, the
two snapshots were not touched in any way since the two send|receive)

 Few final notes. I haven't tried send/receive in a while (they were
 unreliable) so I can't tell which is the last version they worked for
 me (well, no version actually :) ).
 I've never had any problem with just snapshots. I make them regularly,
 I use them, I modify them and I've never had one problem (with 3.17
 too, it's just send/receive that murders them).

 Best regards

 John

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

Some more info I thought off. For me, the corruption problem seems not
to be send related but snapshot creation related. On machine 2 send was
never used. However both filesystems are stored on SSDs (of different
brand). Another filesystem stored on a normal HDD didn't experience the
problem. Maybe this is pure coincidence and has nothing to do with the
fact that it is on SSD or HDD. Another thing I noticed is that for me,
the problem only seems to occur for root subvolumes with many small
files. I have no root subvolumes on HDD so it might be not SSD related.

On 10/12/2014 11:35 PM, David Arendt wrote:
 Just to let you know, I just tried an ls -l on 2 machines running kernel
 3.17 and btrfs-progs 3.16.2.

 Here is my ls -l output:

 Machine 1:
 ls: cannot access root.20141009.000503.backup: Cannot allocate memory
 total 0
 d? ? ?  ? ?? root.20141009.000503.backup
 drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141012.095526.backup
 drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141012.000503.backup
 drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141011.000502.backup
 drwxr-xr-x 1 root   root182 Oct  7 20:35 root.20141010.000502.backup

 root.20141009.000503.backup is not deletable.

 Machine 2:
 ls: cannot access root.20141006.003239.backup: Cannot allocate memory
 ls: cannot access root.20141007.001616.backup: Cannot allocate memory
 ls: cannot access root.20141008.000501.backup: Cannot allocate memory
 ls: cannot access root.20141009.052436.backup: Cannot allocate memory
 total 0
 d? ? ??  ?? root.20141009.052436.backup
 d? ? ??  ?? root.20141008.000501.backup
 d? ? ??  ?? root.20141007.001616.backup
 d? ? ??  ?? root.20141006.003239.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140925.001125.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140924.001017.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140923.001008.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140922.001836.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140921.001029.backup
 drwxr-xr-x 1 root root 232 Aug  3 15:00 root.20140920.001020.backup

 The ? ones are also not deletable.

 Both machines are giving transid verify failed errors.

 I verified my logfiles and this problem was never there using previous
 kernel versions. On machine 1, it is also sure that it was not any
 previous corruption as this filesystem has also been created with
 btrfs-progs 3.16.2 using kernel 3.17.

 On 10/12/2014 05:24 PM, john terragon wrote:
 Hi.

 I just wanted to confirm David's story so to speak :)

 -kernel 3.17-rc7 (didn't bother to compile 3.17 as there weren't any
 btrfs fixes, I think)

 -btrfs-progs 3.16.2 (also compiled from source, so no
 distribution-specific patches)

 -fresh fs

 -I get the same two errors David got (first I got the I/O error one
 and then the memory allocation one)

 -plus now when I ls -la the fs top volume this is what I get

 drwxrwsr-x 1 root staff  30 Sep 11 16:15 home
 d? ? ??   ?? home-backup
 drwxr-xr-x 1 root root  250 Oct 10 15:37 root
 d? ? ??   ?? root-backup
 drwxr-xr-x 1 root root   88 Sep 15 16:02 vms
 drwxr-xr-x 1 root root   88 Sep 15 16:02 vms-backup

 yes, the question marks on those two *-backup snapshots are really
 there. I can't access the snapshots, I can't delete them, I can't do
 anything with them.

 -btrfs check segfaults

 -the events that led to this situation are these:
  1) btrfs su snap -r root root-backup
  2) send |receive (the entire root-backup, not and incremental send)
  immediate I/O error
  3) move on to home: btrfs su snap -r home home-backup
  4) send|receive (again not an incremental send)
  everything goes well (!)
  5) retry with root: btrfs su snap -r root root-backup
  6) send|receive
  and it goes seemingly well
  7) apt-get dist-upgrade just to modify root and try an incremental send
  8) reboot after the dist-upgrade
  9) ls -la the fs top volume: first I get the memory allocation error
 and after that
any ls -la gives the output I pasted above. (notice that beside
 the ls -la, the
two snapshots were not touched in any way since the two send|receive)

 Few final notes. I haven't tried send/receive in a while (they were
 unreliable) so I can't tell which is the last version they worked for
 me (well, no version actually :) ).
 I've never had any problem with just snapshots. I make them regularly,
 I use them, I modify them and I've never had one problem (with 3.17
 too, it's just send/receive that murders them).

 Best regards

 John

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

On 10/07/2014 03:19 PM, Chris Mason wrote:


 On Tue, Oct 7, 2014 at 1:25 AM, David Arendt ad...@prnet.org wrote:
 I did a revert of this commit. After creating a snapshot, the
 filesystem was no longer usable, even with kernel 3.16.3 (crashes 10
 seconds after mount without error message) . Maybe there was some
 previous damage that just appeared now. This evening, I will restore
 from backup and report back.

 On October 7, 2014 12:22:11 AM CEST, Chris Mason c...@fb.com wrote:
 On Mon, Oct 6, 2014 at 4:51 PM, David Arendt ad...@prnet.org wrote:
  I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
  working without any problem. Afterwards I upgraded again to 3.17 and
  the
  problem reappeared. So the problem seems to be kernel version
 related.

 [ backref errors during btrfs-send ]

 Ok then, our list of suspects is pretty short.  Can you easily build
 test kernels?

 I'd like to try reverting this commit:

 51f395ad4058883e4273b02fdebe98072dbdc0d2

 Oh no!  Reverting this definitely should not have caused corruptions,
 so I think the problem was already there.  Do you still have the
 filesystem image?

 Please let us know if you're missing files off the backup, we'll help
 pull them out.

 -chris

 -- 
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
Due to space constraints, it was not possible to take an image of the
corrupted filesystem. As I do backups daily, and the problems occurred 5
hours after backup, no file was lost. Thanks for offering your help. In
4 days I will do some send tests on the newly created filesystem and
report back.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

btrfs send and kernel 3.17

[David Arendt]

Hi,

After upgrading to kernel 3.17 btrfs send has stopped working.

ERROR: send ioctl failed with -5: Input/output error

The following message is printed by kernel:

[75322.782197] BTRFS error (device sda2): did not find backref in
send_root. inode=461, offset=0, disk_byte=1094713344 found extent=1094713344

btrfs inspect-internal inode-resolve -v 461 /u00/root.snapshot returns:

/var/log/emerge-fetch.log

After removing this file, the error moves on to another file.

btrfs scrub output:

scrub status for bc31b068-2c36-4ff2-ac5c-7ce55af5371d
scrub started at Mon Oct  6 19:49:25 2014 and finished after 1748
seconds
total bytes scrubbed: 94.21GiB with 0 errors

Other then the btrfs send problem, the filesystem works normally.

Is this a bug in btrfs-send or is my filesystem corrupted and should be
restored from backup ?

Please tell me if I can do anything else to help debugging this issue.

Thanks in advance,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

I have upgraded from kernel 3.16.3.

emerge-fetch.log is a simple append-only log file. Other files having
the problems after deleting them one by one have been emerge.log,
mysql.log, freshclam.log and main.cvd from clamav. At this one, I
stopped deleting.

On 10/06/2014 09:06 PM, Chris Mason wrote:
 On Mon, Oct 6, 2014 at 2:50 PM, David Arendt ad...@prnet.org wrote:
 Hi,

 After upgrading to kernel 3.17 btrfs send has stopped working.

 ERROR: send ioctl failed with -5: Input/output error

 The following message is printed by kernel:

 [75322.782197] BTRFS error (device sda2): did not find backref in
 send_root. inode=461, offset=0, disk_byte=1094713344 found
 extent=1094713344

 btrfs inspect-internal inode-resolve -v 461 /u00/root.snapshot returns:

 /var/log/emerge-fetch.log

 After removing this file, the error moves on to another file.

 btrfs scrub output:

 scrub status for bc31b068-2c36-4ff2-ac5c-7ce55af5371d
 scrub started at Mon Oct  6 19:49:25 2014 and finished after 1748
 seconds
 total bytes scrubbed: 94.21GiB with 0 errors

 Other then the btrfs send problem, the filesystem works normally.

 Is this a bug in btrfs-send or is my filesystem corrupted and should be
 restored from backup ?

 Please tell me if I can do anything else to help debugging this issue.

 Which kernel did you upgrade from?  I don't think we have changes in
 3.17 that should impact this.

 Is merge-fetch.log just a simple append-only log file?

 -chris



 -- 
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send and kernel 3.17

[David Arendt]

I just tried downgrading to 3.16.3 again. In 3.16.3 btrfs send is
working without any problem. Afterwards I upgraded again to 3.17 and the
problem reappeared. So the problem seems to be kernel version related.

On 10/06/2014 09:06 PM, Chris Mason wrote:
 On Mon, Oct 6, 2014 at 2:50 PM, David Arendt ad...@prnet.org wrote:
 Hi,

 After upgrading to kernel 3.17 btrfs send has stopped working.

 ERROR: send ioctl failed with -5: Input/output error

 The following message is printed by kernel:

 [75322.782197] BTRFS error (device sda2): did not find backref in
 send_root. inode=461, offset=0, disk_byte=1094713344 found
 extent=1094713344

 btrfs inspect-internal inode-resolve -v 461 /u00/root.snapshot returns:

 /var/log/emerge-fetch.log

 After removing this file, the error moves on to another file.

 btrfs scrub output:

 scrub status for bc31b068-2c36-4ff2-ac5c-7ce55af5371d
 scrub started at Mon Oct  6 19:49:25 2014 and finished after 1748
 seconds
 total bytes scrubbed: 94.21GiB with 0 errors

 Other then the btrfs send problem, the filesystem works normally.

 Is this a bug in btrfs-send or is my filesystem corrupted and should be
 restored from backup ?

 Please tell me if I can do anything else to help debugging this issue.

 Which kernel did you upgrade from?  I don't think we have changes in
 3.17 that should impact this.

 Is merge-fetch.log just a simple append-only log file?

 -chris



 -- 
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

your patches seem to fix the problem

Thanks,
David Arendt

On 11/28/12 11:54, Liu Bo wrote:
 On Tue, Nov 27, 2012 at 08:20:54PM +0100, David Arendt wrote:
 Hi,

 I have now tested a gentoo reinstall with a recompile of nfs-utils. By
 observing how the directory /var/lib/nfs is created, I found a rather
 simple way to reproduce the problem:
 Thanks for the reproduce steps, it helps quite a lot.

 It turns out to be something wrong in btrfs's setting xattr code, I've
 just sent you two patches for it, maybe you can check to see if it works
 on your box :)

 thanks,
 liubo

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

I tried to create an ext4 filesystem on a loop device and do a cp -a of
/var/lib/nfs/sm to the ext4 filesystem. Here the problem does not exist.
Perhaps ext4 has another behaviour in the sense that it doesn't store
empty attributes or doesn't return empty attributes.

I am using Gentoo and will try to do a new install on a loop device to
figure out which userspace program creates files this way.

Thanks in advance,
David Arendt

On 11/27/12 08:46, Liu Bo wrote:
 Hi,  
  
 (cc btrfs Mailing list to notify others.)

 Thanks for the helpful test.img.

 Well...after deeper debug, I'm sure that it's not a btrfs bug,
 at least not a btrfs acl/xattr bug. 
  
 The debug tree shows 
  
 item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
 inode generation 6 transid 6 size 102 block group 0 mode 40755 links 
 1 
 item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
 inode ref index 2 namelen 5 name: test1 
 item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
 location key (0 UNKNOWN.0 0) type 8 
 namelen 24 datalen 0 name: system.posix_acl_default 
   ^^^ 
 item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
 location key (0 UNKNOWN.0 0) type 8 
 namelen 23 datalen 28 name: system.posix_acl_access 
 data ^B 
  
 == 

 so extended attribute system.posix_acl_default here has not data, which'll
 make filesystems(not just btrfs) return -ENODATA. 
  
 I guess some userspace applications may make it like that. 
  
 thanks, 
 liubo

 On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
 Hi,

 I don't know if your xattr patch was meant to fix this issue, but I have
 just tested kernel 3.7-rc7 with your patch applied on another directory
 having the problem and I still have the weird behaviour.

 Thanks in advance,
 David Arendt

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

I have now tested a gentoo reinstall with a recompile of nfs-utils. By
observing how the directory /var/lib/nfs is created, I found a rather
simple way to reproduce the problem:

dd if=/dev/zero of=test.img bs=8192 count=81920
81920+0 records in
81920+0 records out
671088640 bytes (671 MB) copied, 1.52943 s, 439 MB/s

losetup /dev/loop0 test.img

mkfs.btrfs /dev/loop0

WARNING! - Btrfs v0.20-rc1-37-g91d9eec IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

SMALL VOLUME: forcing mixed metadata/data groups
Created a data/metadata chunk of size 8388608
fs created label (null) on /dev/loop0
nodesize 4096 leafsize 4096 sectorsize 4096 size 640.00MB
Btrfs v0.20-rc1-37-g91d9eec

mount /dev/loop0 /mnt

btrfs subvolume create /mnt/test
Create subvolume '/mnt/test'

mkdir /mnt/test/test1

/root/x/testxattr /mnt/test/test1 
processing file /mnt/test/test1

cp -a /mnt/test/test1 /mnt/test/test2

/root/x/testxattr /mnt/test/test2
processing file /mnt/test/test2
processing attribute system.posix_acl_default
lgetxattr failed: No data available

Might it be a bug in coreutils ?

Thanks in advance,
David Arendt

On 11/27/12 08:46, Liu Bo wrote:
 Hi,  
  
 (cc btrfs Mailing list to notify others.)

 Thanks for the helpful test.img.

 Well...after deeper debug, I'm sure that it's not a btrfs bug,
 at least not a btrfs acl/xattr bug. 
  
 The debug tree shows 
  
 item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
 inode generation 6 transid 6 size 102 block group 0 mode 40755 links 
 1 
 item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
 inode ref index 2 namelen 5 name: test1 
 item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
 location key (0 UNKNOWN.0 0) type 8 
 namelen 24 datalen 0 name: system.posix_acl_default 
   ^^^ 
 item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
 location key (0 UNKNOWN.0 0) type 8 
 namelen 23 datalen 28 name: system.posix_acl_access 
 data ^B 
  
 == 

 so extended attribute system.posix_acl_default here has not data, which'll
 make filesystems(not just btrfs) return -ENODATA. 
  
 I guess some userspace applications may make it like that. 
  
 thanks, 
 liubo

 On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
 Hi,

 I don't know if your xattr patch was meant to fix this issue, but I have
 just tested kernel 3.7-rc7 with your patch applied on another directory
 having the problem and I still have the weird behaviour.

 Thanks in advance,
 David Arendt

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

I have made some more tests:

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_default
lgetxattr failed: No data available

getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
(no result)

setfattr -x system.posix_acl_default
/u00/root.20121121.210102.full/var/lib/nfs/sm

testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_access

setfattr -x system.posix_acl_access
/u00/root.20121121.210102.full/var/lib/nfs/sm

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm

Now a test with a manually set attribute:

setfattr -n user.testattribute -v testvalue
/u00/root.20121121.210102.full/var/lib/nfs/sm

getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
getfattr: Removing leading '/' from absolute path names
# file: u00/root.20121121.210102.full/var/lib/nfs/sm
user.testattribute

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/smprocessing file
/u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute user.testattribute
value testvalue

Thanks in advance,
David Arendt

On 11/24/12 04:39, Liu Bo wrote:
 On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
 Well, this is only code to demonstrate the problem, the ; is normally a
 silly mistake, but for my test case valuelen is  0 so, the ; doesn't
 change anything. With this corrected, the problem stays the same.

 On 11/23/12 21:43, Garry T. Williams wrote:
 On Friday, November 23, 2012 18:45:04 David Arendt wrote:
   for (i = 0; i  attrslen; i+= strlen(attrs[i]) + 1)
   {
 printf(processing attribute %s\n, attrs[i]);

 valuelen = lgetxattr(argv[1], attrs[i], value, 1024);

 if (valuelen  0);
   Hmmm ^
 Hi David,

 Any dmesg output for this?

 thanks,
 liubo



 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

extended attributes wiredness

[David Arendt]

Hi,

I am using kernel 3.7-rc6.

I have written a test application for extended attributes and have for
some folders a wired behaviour:

#include stdio.h
#include string.h
#include attr/xattr.h

char attrs[1024];
ssize_t attrslen;
int i;
char value[1024];
ssize_t valuelen;

int main(int argc, char *argv[])
{
  if (argc != 2)
  {
fprintf(stderr, Syntax: testxattr filename\n);

return 1;
  }

  printf(processing file %s\n, argv[1]);

  attrslen = llistxattr(argv[1], attrs, 1024);

  if (attrslen  0)
  {
perror(listxattr failed);

return 1;
  }

  for (i = 0; i  attrslen; i+= strlen(attrs[i]) + 1)
  {
printf(processing attribute %s\n, attrs[i]);

valuelen = lgetxattr(argv[1], attrs[i], value, 1024);

if (valuelen  0);
{
  perror(lgetxattr failed);

  return 1;
}

printf(value %.*s, (int) valuelen, value);
  }

  return 0;
}

is returning:

processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_default
lgetxattr failed: No data available

output of stat:

File: '/u00/root.20121121.210102.full/var/lib/nfs/sm'
Size: 94Blocks: 0  IO Block: 4096   directory
Device: 3ah/58dInode: 1331353 Links: 1
Access: (0755/drwxr-xr-x)  Uid: (65534/  nobody)   Gid: (0/root)
Access: 2012-10-18 21:25:11.35993 +0200
Modify: 2012-11-21 06:32:24.050210417 +0100
Change: 2012-11-21 06:32:24.050210417 +0100
Birth: -

Is this a bug in btrfs or do I miss something here ?

Thanks in advance,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Well, this is only code to demonstrate the problem, the ; is normally a
silly mistake, but for my test case valuelen is  0 so, the ; doesn't
change anything. With this corrected, the problem stays the same.

On 11/23/12 21:43, Garry T. Williams wrote:
 On Friday, November 23, 2012 18:45:04 David Arendt wrote:
   for (i = 0; i  attrslen; i+= strlen(attrs[i]) + 1)
   {
 printf(processing attribute %s\n, attrs[i]);

 valuelen = lgetxattr(argv[1], attrs[i], value, 1024);

 if (valuelen  0);
   Hmmm ^




--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

There is no dmesg output.

Thanks in advance,
David Arendt

On 11/24/12 04:39, Liu Bo wrote:
 On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
 Well, this is only code to demonstrate the problem, the ; is normally a
 silly mistake, but for my test case valuelen is  0 so, the ; doesn't
 change anything. With this corrected, the problem stays the same.

 On 11/23/12 21:43, Garry T. Williams wrote:
 On Friday, November 23, 2012 18:45:04 David Arendt wrote:
   for (i = 0; i  attrslen; i+= strlen(attrs[i]) + 1)
   {
 printf(processing attribute %s\n, attrs[i]);

 valuelen = lgetxattr(argv[1], attrs[i], value, 1024);

 if (valuelen  0);
   Hmmm ^
 Hi David,

 Any dmesg output for this?

 thanks,
 liubo



 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send/receive symlink bug

[David Arendt]

Hi,

thanks,

this patch fixes the problem

Bye,
David Arendt

On 11/15/12 05:21, Marios Titas wrote:
 On Wed, Nov 14, 2012 at 5:34 PM, David Arendt ad...@prnet.org wrote:
 Hi,

 I am using kernel 3.7.0-rc5 and latest btrfs-progs git.

 I am trying btrfs send/receive. When I have a filesystem containing a
 symlink pointing to a nonexistent destination or a destination created
 after the symlink was created, btrfs receive aborts with: ERROR: chown
 link1.txt failed. No such file or directory.

 Steps to reproduce (/dev/loop0 and /dev/loop1 are test images):

 mkfs.btrfs /dev/loop0
 mount /dev/loop0 /u00
 btrfs subvolume create /u00/test
 cd /u00/test
 ln -s test1.txt link1.txt
 btrfs subvolume snapshot -r /u00/test /u00/test.snapshot
 mkfs.btrfs /dev/loop1
 mount /dev/loop1 /u01
 btrfs send /u00/test.snapshot | btrfs receive /u01
 ERROR: chown link1.txt failed. No such file or directory

 A patch [1] for btrfs-progs that solves this issue was posted a month
 ago but has landed yet on the btrfs-progs git repository.

 [1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg19539.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Default to read-only on snapshot creation and have a flag if snapshot should be writable (was: [PATCH 0/5] btrfs: Readonly snapshots)

[David Arendt]

On 11/29/10 21:02, Mike Fedyk wrote:

On Mon, Nov 29, 2010 at 12:02 AM, Li Zefanl...@cn.fujitsu.com  wrote:

(Cc: Sage Weils...@newdream.net  for changes in async snapshots)

This patchset adds readonly-snapshots support. You can create a
readonly snapshot, and you can also set a snapshot readonly/writable
on the fly.

A few readonly checks are added in setattr, permission, remove_xattr
and set_xattr callbacks, as well as in some ioctls.


Great work!

I have a suggestion on defaults when snapshots are created.  I think
they should default to being read-only and if they are meant to be
read-write a flag can be set at creation time (and changable at a
later time as well of course).

This way user/admin preconceptions of a snapshot being read-only can
be enforced by default, and the exception when you want a read-write
snapshot can be available with a switch at the cli level (and probably
a flag at the ioctl level).

It gives one more natural distinction between a snapshot and a
subvolume at the user conceptual level.

What do you think?
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

I completely agree with you. I think lots of people use snapshots for 
backup purposes and these ones shouldn't be writable.


Bye,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Gentoo amd64 based rescue cd supporting nilfs2 and btrfs

[David Arendt]

Hi,

As I like experimenting with file systems, and as lots of boot cds don't 
have the latest kernel/userspace tools, I decided to create my own 
bootcd for my personal use. As I think it could be interesting for other 
people, I made it available at http://prrescue.prnet.org


Bye,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

btrfs: unlinked 34 orphans

[David Arendt]

Hi,

I received the message: btrfs: unlinked 34 orphans

Just out of couriosity: what does it mean ?

Thanks in advance
Bye,
David Arendt
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html