Starting btrfs defrag with xargs -P 2 locks

[Jérôme Poulin]

I was de-fragmenting a BTRFS recently and it was quite slow, so I
decided to pipe find output to xargs -P 2 to speed up the file listing
process and found out it breaks BTRFS quite fast. In 2 minutes, I had
this in dmesg. As expected, btrfs command is deadlocked.

btrfs-progs v4.2.2


[3650924.735400] [ cut here ]
[3650924.735423] WARNING: CPU: 3 PID: 3561 at
/home/zumbi/linux-4.3.5/fs/btrfs/locking.c:46
btrfs_set_lock_blocking_rw+0xa2/0xb0 [btrfs]()
[3650924.735424] Modules linked in: dccp_diag dccp udp_diag unix_diag
ipt_REJECT nf_reject_ipv4 nf_log_ipv6 ip_vs_rr xt_ipvs ip_vs
ip6table_filter xt_conntrack xt_multiport xt_limit xt_nat squashfs
tcp_diag inet_diag nf_log_ipv4 nf_log_common xt_LOG xt_u32 xt_tcpudp
xt_hashlimit xt_recent iptable_filter dm_snapshot dm_bufio veth
vhost_net vhost macvtap macvlan tun cbc rbd libceph libcrc32c
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 binfmt_misc
ip6_tables xt_REDIRECT nf_nat_redirect iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc arc4 ecb md4
hmac nls_utf8 cifs dns_resolver fscache nbd bridge bonding btrfs
iTCO_wdt iTCO_vendor_support evdev coretemp ttm kvm_intel
drm_kms_helper kvm
[3650924.735464]  drm pcspkr dcdbas i7core_edac i2c_algo_bit edac_core
acpi_power_meter 8250_fintek button acpi_cpufreq lpc_ich tpm_tis tpm
mfd_core shpchp processor 8021q garp mrp stp llc loop ipmi_watchdog
ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse parport_pc
ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 dm_mod raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq raid1 md_mod sg sd_mod uas usb_storage crc32c_intel mvsas
libsas ehci_pci libata ehci_hcd scsi_transport_sas bnx2 usbcore
usb_common scsi_mod
[3650924.735497] CPU: 3 PID: 3561 Comm: btrfs Tainted: GW
 4.3.0-0.bpo.1-amd64 #1 Debian 4.3.5-1~bpo8+1
[3650924.735499] Hardware name: Dell Inc. PowerEdge R310/05XKKK, BIOS
1.5.2 10/15/2010
[3650924.735500]   b671a633 812e1ac9

[3650924.735502]  81074451 880039cc3a28 
8800b7528b80
[3650924.735504]  880039cc3a28 8801fbe7eae0 a0597c22
01ec
[3650924.735507] Call Trace:
[3650924.735512]  [] ? dump_stack+0x40/0x57
[3650924.735515]  [] ? warn_slowpath_common+0x81/0xb0
[3650924.735530]  [] ?
btrfs_set_lock_blocking_rw+0xa2/0xb0 [btrfs]
[3650924.735537]  [] ? btrfs_realloc_node+0xcc/0x490 [btrfs]
[3650924.735551]  [] ? btrfs_defrag_leaves+0x1ed/0x360 [btrfs]
[3650924.735562]  [] ? btrfs_defrag_root+0x56/0xe0 [btrfs]
[3650924.735576]  [] ? btrfs_ioctl_defrag+0x126/0x170 [btrfs]
[3650924.735590]  [] ? btrfs_ioctl+0x1873/0x20f0 [btrfs]
[3650924.735593]  [] ? list_del+0x9/0x20
[3650924.735596]  [] ? remove_wait_queue+0x20/0x30
[3650924.735598]  [] ? n_tty_write+0x28a/0x4e0
[3650924.735602]  [] ? do_vfs_ioctl+0x2d5/0x4b0
[3650924.735605]  [] ? vfs_write+0x143/0x190
[3650924.735607]  [] ? SyS_ioctl+0x76/0x90
[3650924.735611]  [] ? system_call_fast_compare_end+0xc/0x6b
[3650924.735612] ---[ end trace 0c5cdef70670d5c5 ]---
[3650924.735628] [ cut here ]
[3650924.793031] kernel BUG at /home/zumbi/linux-4.3.5/fs/btrfs/locking.c:295!
[3650924.876593] invalid opcode:  [#1] SMP
[3650924.927896] Modules linked in: dccp_diag dccp udp_diag unix_diag
ipt_REJECT nf_reject_ipv4 nf_log_ipv6 ip_vs_rr xt_ipvs ip_vs
ip6table_filter xt_conntrack xt_multiport xt_limit xt_nat squashfs
tcp_diag inet_diag nf_log_ipv4 nf_log_common xt_LOG xt_u32 xt_tcpudp
xt_hashlimit xt_recent iptable_filter dm_snapshot dm_bufio veth
vhost_net vhost macvtap macvlan tun cbc rbd libceph libcrc32c
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 binfmt_misc
ip6_tables xt_REDIRECT nf_nat_redirect iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd grace sunrpc arc4 ecb md4
hmac nls_utf8 cifs dns_resolver fscache nbd bridge bonding btrfs
iTCO_wdt iTCO_vendor_support evdev coretemp ttm kvm_intel
drm_kms_helper kvm
[3650925.783705]  drm pcspkr dcdbas i7core_edac i2c_algo_bit edac_core
acpi_power_meter 8250_fintek button acpi_cpufreq lpc_ich tpm_tis tpm
mfd_core shpchp processor 8021q garp mrp stp llc loop ipmi_watchdog
ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse parport_pc
ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 dm_mod raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq raid1 md_mod sg sd_mod uas usb_storage crc32c_intel mvsas
libsas ehci_pci libata ehci_hcd scsi_transport_sas bnx2 usbcore
usb_common scsi_mod
[3650926.350014] CPU: 3 PID: 3561 Comm: btrfs Tainted: GW
 4.3.0-0.bpo.1-amd64 #1 Debian 4.3.5-1~bpo8+1
[3650926.473013] Hardware name: Dell Inc. PowerEdge R310/05XKKK, BIOS
1.5.2 10/15/2010
[3650926.564902] task: 8800a03acf80 ti: 8800242a8000 

Re: csum failed on innexistent inode

[Jérôme Poulin]

On Sun, Apr 10, 2016 at 1:25 PM, Henk Slager  wrote:
> Kernel/tools
> versions and btrfs fi us output might also give some hints.


I completely forgot to paste those:
BTRFS: btrfs-progs v4.4
Kernel: 4.6.0-rc2.
--
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: csum failed on innexistent inode

[Jérôme Poulin]

Sorry for the confusion, allow me to clarify and I will summarize with
what I learned since I now understand that corruption was present
before disk went bad.

Note that this BTRFS was once on a MD RAID5 on LVM on LUKS before
being moved in-place to LVM on LUKS on BTRFS RAID10. But since balance
worked at the time.

Also note that this computer was booted twice for about 30 minutes
period with bad ram before it was replaced.

I think my checksums errors were present, but unknown to me, before
the hardware disk failure. The bad memory might be the root cause of
this problem but I can't be sure.


On Sun, Apr 10, 2016 at 1:25 PM, Henk Slager  wrote:
> It was not fully clear what the sequence of events were:
> - HW problem
> - btrfs SW problem
> - 1st scrub
> - the --repair-sector with hdparm
> - 2nd scrub
> - 3rd scrub?
>

1. Errors in dmesg and confirmation from smartd that hardware problems
were present.
2. Attempt to repair sector using --repair-sector which reset the
sector to zeroes.
3. Scrub detected errors and fixed some but there were 18 uncorrectable.
4. Disk has been changed using btrfs replace. Corruption still present.
5. Balance attempted but aborts when encountering the first uncorrectable error.
6. Tentative to locate bad sector/inode without success leading to
another scrub with the same errors.
7. Attempt to reset stats and scrub again. Still getting the same errors.
8. New disk added and data profile converted from RAID10 to RAID1,
balance abort on first uncorrectable error.


> There is also DM between the harddisk and btrfs and I am not sure if
> whether the hdparm action did repair or further corrupt things.
>

I confirmed after using --repair-sector that the sector has been reset
to zeroes using --read-sector. I also tried read-sector first which
failed and added an entry to the SMART log. After repair-sector,
read-sector returned the zeroed sector.

> How do you know for sure that the contents of the 'logical blocks' are
> the same on both devices?
>

After a balance, here is what dmesg shows (complete warning output):
BTRFS warning (device dm-36): csum failed ino 330 off 1809084416 csum
4147641019 expected csum 1755301217
BTRFS warning (device dm-36): csum failed ino 330 off 1809195008 csum
1515428513 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809199104 csum
1927504681 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809211392 csum
3086571080 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809149952 csum
3254083717 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809162240 csum
3157020538 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809166336 csum
1092724678 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809178624 csum
4235459038 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809182720 csum
1764946502 expected csum 2566472073
BTRFS warning (device dm-36): csum failed ino 330 off 1809084416 csum
4147641019 expected csum 1755301217


After a scrub (complete error output):
BTRFS error (device dm-36): bdev /dev/dm-32 errs: wr 0, rd 0, flush 0,
corrupt 1, gen 0
BTRFS error (device dm-36): bdev /dev/dm-32 errs: wr 0, rd 0, flush 0,
corrupt 2, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334876672 on dev /dev/dm-32
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334987264 on dev /dev/dm-32
BTRFS error (device dm-36): bdev /dev/dm-32 errs: wr 0, rd 0, flush 0,
corrupt 3, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334991360 on dev /dev/dm-32
BTRFS error (device dm-36): bdev /dev/dm-32 errs: wr 0, rd 0, flush 0,
corrupt 4, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296335003648 on dev /dev/dm-32
BTRFS error (device dm-36): bdev /dev/dm-36 errs: wr 0, rd 0, flush 0,
corrupt 1, gen 0
BTRFS error (device dm-36): bdev /dev/dm-36 errs: wr 0, rd 0, flush 0,
corrupt 2, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334876672 on dev /dev/dm-36
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334987264 on dev /dev/dm-36
BTRFS error (device dm-36): bdev /dev/dm-36 errs: wr 0, rd 0, flush 0,
corrupt 3, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334991360 on dev /dev/dm-36
BTRFS error (device dm-36): bdev /dev/dm-36 errs: wr 0, rd 0, flush 0,
corrupt 4, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296335003648 on dev /dev/dm-36
BTRFS error (device dm-36): bdev /dev/dm-35 errs: wr 0, rd 0, flush 0,
corrupt 1, gen 0
BTRFS error (device dm-36): unable to fixup (regular) error at logical
1296334942208 on dev /dev/dm-35
BTRFS error (device dm-36): bdev /dev/dm-35 errs: wr 0, rd 0, flush 0,
corrupt 2, 

Re: csum failed on innexistent inode

[Jérôme Poulin]

On Mon, Apr 4, 2016 at 5:42 AM, Henk Slager  wrote:
>
> You might want this patch:
> http://www.spinics.net/lists/linux-btrfs/msg53552.html
>
> As workaround, you can reset the counters on new/healty device with:
>
> btrfs device stats [-z] |
>

I did reset the stats and launched another scrub, and still, since the
logical blocks are the same on both devices and checksum is different,
is really seems like my problem was originally created when I booted
this computer with bad memory (maybe?), could it have been that the
checksum was saved on disk as bad in the first place and BTRFS doesn't
want to read it back?

Is it possible to reset the checksum on those? I couldn't find what
file or metadata the blocks were pointing too.


> >
> > btrfs check:
> > ./btrfs check /dev/mapper/luksbtrfsdata2
> > Checking filesystem on /dev/mapper/luksbtrfsdata2
> > UUID: 805f6ad7-1188-448d-aee4-8ddeeb70c8a7
> > checking extents
> > bad metadata [1453741768704, 1453741785088) crossing stripe boundary
> > bad metadata [1454487764992, 1454487781376) crossing stripe boundary
> > bad metadata [1454828552192, 1454828568576) crossing stripe boundary
> > bad metadata [1454879735808, 1454879752192) crossing stripe boundary
> > bad metadata [1455087222784, 1455087239168) crossing stripe boundary
> > bad metadata [1456269426688, 1456269443072) crossing stripe boundary
> > bad metadata [1456273227776, 1456273244160) crossing stripe boundary
> > bad metadata [1456404234240, 1456404250624) crossing stripe boundary
> > bad metadata [1456418914304, 1456418930688) crossing stripe boundary
>
> Those are false alerts; This patch handles that:
> https://patchwork.kernel.org/patch/8706891/
>

Since those are fakes, I'll just ignore them for now.
--
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: csum failed on innexistent inode

[Jérôme Poulin]

On Mon, Apr 4, 2016 at 4:17 PM, Kai Krakow <hurikha...@gmail.com> wrote:
>
> Am Mon, 4 Apr 2016 03:50:54 -0400
> schrieb Jérôme Poulin <jeromepou...@gmail.com>:
>
> > How is it possible to get rid of the referenced csum errors if they do
> > not exist? Also, the expected checksum looks suspiciously the same for
> > multiple errors. Could it be bad RAM in that case? Can I convince
> > BTRFS to update the csum?
> >
> > # btrfs inspect-internal logical-resolve -v 1809149952 /mnt/btrfs/
> > ioctl ret=-1, error: No such file or directory
> > # btrfs inspect-internal inode-resolve -v 296 /mnt/btrfs/
> > ioctl ret=-1, error: No such file or directory
>
> I fell into that pitfall, too. If you have multiple subvolumes, you
> need to pass the correct subvolume path for the inode to properly
> resolve.
>
> Maybe that's the case for you?
>

You are absolutely right for the inode case, however, that did not
help for logical-resolve.

The file found by the inode does not seem to be corrupted though.

# btrfs sub li /mnt/btrfs/ | cut -d' ' -f9 | xargs -n1 btrfs inspect
logical-resolve -v 1809149952
ioctl ret=-1, error: No such file or directory
ioctl ret=-1, error: No such file or directory
ioctl ret=-1, error: No such file or directory
ioctl ret=-1, error: No such file or directory
...

# btrfs sub li /mnt/btrfs/ | cut -d' ' -f9 | xargs -n1 btrfs inspect
inode-resolve -v 296
ioctl ret=-1, error: No such file or directory
ioctl ret=0, bytes_left=4018, bytes_missing=0, cnt=1, missed=0
backups/runboy/data/www/dev/.virtualenv/lib/python3.4/_collections_abc.py
ioctl ret=0, bytes_left=4018, bytes_missing=0, cnt=1, missed=0
backups@2016-03-23-01-56/www/dev/.virtualenv/lib/python3.4/_collections_abc.py
ioctl ret=0, bytes_left=4018, bytes_missing=0, cnt=1, missed=0
backups@2016-03-23-02-04/www/dev/.virtualenv/lib/python3.4/_collections_abc.py
ioctl ret=0, bytes_left=4018, bytes_missing=0, cnt=1, missed=0
backups@2016-03-23-05-05/www/dev/.virtualenv/lib/python3.4/_collections_abc.py
ioctl ret=0, bytes_left=4018, bytes_missing=0, cnt=1, missed=0
...
--
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

csum failed on innexistent inode

[Jérôme Poulin]

Hi all,

I have a BTRFS on disks running in RAID10 meta+data, one of the disk
has been going bad and scrub was showing 18 uncorrectable errors
(which is weird in RAID10). I tried using --repair-sector with hdparm
even if it shouldn't be necessary since BTRFS would overwrite the
sector. Repair sector fixed the sector in SMART but BTRFS was still
showing 18 uncorr. errors.

I finally decided to give up this opportunity to test the error
correction property of BTRFS (this is a home system, backed up) and
installed a brand new disk in the machine. After running btrfs
replace, everything was fine, I decided to run btrfs scrub again and I
still have the same 18 uncorrectable errors.

Later on, since I had a new disk with more space, I decided to run a
balance to free up the new space but the balance has stopped with csum
errors too. Here are the output of multiple programs.

How is it possible to get rid of the referenced csum errors if they do
not exist? Also, the expected checksum looks suspiciously the same for
multiple errors. Could it be bad RAM in that case? Can I convince
BTRFS to update the csum?

# btrfs inspect-internal logical-resolve -v 1809149952 /mnt/btrfs/
ioctl ret=-1, error: No such file or directory
# btrfs inspect-internal inode-resolve -v 296 /mnt/btrfs/
ioctl ret=-1, error: No such file or directory


dmesg after first bad sector:
avr 01 18:29:52 p4.i.ticpu.net kernel: BTRFS info (device dm-43): read
error corrected: ino 1 off 655368716288 (dev /dev/dm-42 sector
2939136)
avr 01 18:29:52 p4.i.ticpu.net kernel: BTRFS info (device dm-43): read
error corrected: ino 1 off 655368720384 (dev /dev/dm-42 sector
2939144)
avr 01 18:29:52 p4.i.ticpu.net kernel: BTRFS info (device dm-43): read
error corrected: ino 1 off 655368724480 (dev /dev/dm-42 sector
2939152)
avr 01 18:29:52 p4.i.ticpu.net kernel: BTRFS info (device dm-43): read
error corrected: ino 1 off 655368728576 (dev /dev/dm-42 sector
2939160)

dmesg after balance:
[1738474.444648] BTRFS warning (device dm-40): csum failed ino 296 off
1809195008 csum 1515428513 expected csum 2566472073
[1738474.444649] BTRFS warning (device dm-40): csum failed ino 296 off
1809084416 csum 4147641019 expected csum 1755301217
[1738474.444702] BTRFS warning (device dm-40): csum failed ino 296 off
1809199104 csum 1927504681 expected csum 2566472073
[1738474.444717] BTRFS warning (device dm-40): csum failed ino 296 off
1809211392 csum 3086571080 expected csum 2566472073
[1738474.444917] BTRFS warning (device dm-40): csum failed ino 296 off
1809084416 csum 4147641019 expected csum 1755301217
[1738474.444962] BTRFS warning (device dm-40): csum failed ino 296 off
1809195008 csum 1515428513 expected csum 2566472073
[1738474.444998] BTRFS warning (device dm-40): csum failed ino 296 off
1809199104 csum 1927504681 expected csum 2566472073
[1738474.445034] BTRFS warning (device dm-40): csum failed ino 296 off
1809211392 csum 3086571080 expected csum 2566472073
[1738474.473286] BTRFS warning (device dm-40): csum failed ino 296 off
1809149952 csum 3254083717 expected csum 2566472073
[1738474.473357] BTRFS warning (device dm-40): csum failed ino 296 off
1809162240 csum 3157020538 expected csum 2566472073

btrfs check:
./btrfs check /dev/mapper/luksbtrfsdata2
Checking filesystem on /dev/mapper/luksbtrfsdata2
UUID: 805f6ad7-1188-448d-aee4-8ddeeb70c8a7
checking extents
bad metadata [1453741768704, 1453741785088) crossing stripe boundary
bad metadata [1454487764992, 1454487781376) crossing stripe boundary
bad metadata [1454828552192, 1454828568576) crossing stripe boundary
bad metadata [1454879735808, 1454879752192) crossing stripe boundary
bad metadata [1455087222784, 1455087239168) crossing stripe boundary
bad metadata [1456269426688, 1456269443072) crossing stripe boundary
bad metadata [1456273227776, 1456273244160) crossing stripe boundary
bad metadata [1456404234240, 1456404250624) crossing stripe boundary
bad metadata [1456418914304, 1456418930688) crossing stripe boundary
checking free space cache
checking fs roots
checking csums
checking root refs
found 689292505473 bytes used err is 0
total csum bytes: 660112536
total tree bytes: 1764098048
total fs tree bytes: 961921024
total extent tree bytes: 79331328
btree space waste bytes: 232774315
file data blocks allocated: 4148513517568
 referenced 972284129280

btrfs scrub:
I don't have the output handy but the dmesg output were pairs of
logical blocks like balance and no errors were corrected.
--
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: [PATCH 2/3] btrfs-progs: add 'du' command

[Jérôme Poulin]

On Wed, Jan 20, 2016 at 4:49 PM, Mark Fasheh  wrote:
> 'btrfs du' differs from regular du in that it will work to resolve which
> blocks are shared between files in its list. This gives the user a more
> accurate bytecount from which they can make decisions regarding management
> of their file space.


Would it be a good idea for this new du to show the compressed file size too?

It was not made by me but I know I had this patch lying around, it
also does not compile right now but I could give it an update. The
wiki says this patch was "not merged yet" but I have no idea why it
was not since it was working correctly 2 years ago on my machine.

---
 fs/btrfs/ioctl.c   | 77 ++
 include/uapi/linux/btrfs.h |  2 ++
 2 files changed, 79 insertions(+)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index da94138..1c6285b 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -4499,6 +4499,81 @@ static int build_ino_list(u64 inum, u64 offset,
u64 root, void *ctx)
 return 0;
 }

+/*
+ * Returns the compressed size of an inode in 512 byte blocks.
+ * Count the on-disk space used by extents starting in range [start, end),
+ * inline data are rounded up to sector, ie. 512.
+ *
+ * The range is start inclusive and end exclusive so it can be used to
+ * determine compressed size of a given extent by its start and start of the
+ * next extent easily, without counting length.
+ * Whole file is specified as start = 0, end = (u64)-1
+ */
+static long btrfs_ioctl_compr_size(struct file *file, void __user *argp)
+{
+struct inode *inode = fdentry(file)->d_inode;
+struct btrfs_ioctl_compr_size_args compr_args;
+u64 len;
+u64 compressed_size = 0;
+u64 offset = 0;
+
+if (S_ISDIR(inode->i_mode))
+return -EISDIR;
+
+if (copy_from_user(_args, argp,
+sizeof(struct btrfs_ioctl_compr_size_args)))
+return -EFAULT;
+
+if (compr_args.start > compr_args.end)
+return -EINVAL;
+
+mutex_lock(>i_mutex);
+
+offset = compr_args.start;
+if (inode->i_size > compr_args.end)
+len = compr_args.end;
+else
+len = inode->i_size;
+
+/*
+ * do any pending delalloc/csum calc on inode, one way or
+ * another, and lock file content
+ */
+btrfs_wait_ordered_range(inode, compr_args.start, len);
+
+while (offset < len) {
+struct extent_map *em;
+
+em = btrfs_get_extent(inode, NULL, 0, offset, 1, 0);
+if (IS_ERR_OR_NULL(em))
+goto error;
+if (em->block_len != (u64)-1)
+compressed_size += em->block_len;
+else if (em->block_start == EXTENT_MAP_INLINE) {
+compressed_size += ALIGN(em->len, 512);
+}
+offset += em->len;
+free_extent_map(em);
+}
+mutex_unlock(>i_mutex);
+
+unlock_extent(_I(inode)->io_tree, compr_args.start, len);
+
+compr_args.size = compressed_size >> 9;
+
+if (copy_to_user(argp, _args, sizeof(struct
+btrfs_ioctl_compr_size_args)))
+return -EFAULT;
+
+return 0;
+
+error:
+mutex_unlock(>i_mutex);
+unlock_extent(_I(inode)->io_tree, compr_args.start, len);
+
+return -EIO;
+}
+
 static long btrfs_ioctl_logical_to_ino(struct btrfs_root *root,
 void __user *arg)
 {
@@ -5532,6 +5607,8 @@ long btrfs_ioctl(struct file *file, unsigned int
 return btrfs_ioctl_scrub_progress(root, argp);
 case BTRFS_IOC_BALANCE_V2:
 return btrfs_ioctl_balance(file, argp);
+case BTRFS_IOC_COMPR_SIZE:
+return btrfs_ioctl_compr_size(file, argp);
 case BTRFS_IOC_BALANCE_CTL:
 return btrfs_ioctl_balance_ctl(root, arg);
 case BTRFS_IOC_BALANCE_PROGRESS:
diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
index dea8931..cd52cda 100644
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -647,6 +647,8 @@ static inline char *btrfs_err_str(enum
btrfs_err_code err_code)
char[BTRFS_LABEL_SIZE])
 #define BTRFS_IOC_SET_FSLABEL _IOW(BTRFS_IOCTL_MAGIC, 50, \
char[BTRFS_LABEL_SIZE])
+#define BTRFS_IOC_COMPR_SIZE _IOR(BTRFS_IOCTL_MAGIC, 51, \
+struct btrfs_ioctl_compr_size_args)
 #define BTRFS_IOC_GET_DEV_STATS _IOWR(BTRFS_IOCTL_MAGIC, 52, \
   struct btrfs_ioctl_get_dev_stats)
 #define BTRFS_IOC_DEV_REPLACE _IOWR(BTRFS_IOCTL_MAGIC, 53, \
-- 
2.7.0
--
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

Out of memory purging snapshots

[Jérôme Poulin]

Hello everyone,

I have encountered a weird out of memory problem using BTRFS,
snapshots and duperemove.
The workload is described as:
- Lots of static (400G/1T) data which was deduplicated using
duperemove which saved about 50GB.
- Backups are saved to the BTRFS every 2 days, backup take about 2 hours.
- Backups are deduped every weeks.
- Snapshots are taken every hour for 10 days.

After about 10 days worth of snapshot and 8 days worth of dedupe, the
system started slowing down after each snapshot removal.

I decided to wipe all snapshots and stop de-duping data, I proceeded
and removed snapshots 8 at a time, waiting for btrfs-transaction to
stop. After some time, PC locked up and I could not do anything else
but restart, reboot was caused because of the free memory and cache
being all used up. It seems the kernel module could not use any swap
and out of memory killer had no victim.

I was able to start the operation again by mounting using
thread_pool=1 and stopping all services, it went well for the first
~100 snapshots but then the condition appeared again, after multiple
attemps I tried mounting R/O and it worked.

I currently have a VM up on this machine which has 3GB RAM, the VM has
now 4GB RAM and the host has 4GB additional swap. It is currently
making progress but I think this might be considered as a bug. I have
some dmesg logs showing the problem.

16:53:17 srv kernel: [   68.040380] BTRFS info (device dm-6): disk
space caching is enabled
16:53:17 srv kernel: [   68.040385] BTRFS: has skinny extents
16:56:09 srv kernel: [  240.112032] INFO: task kworker/u8:6:162
blocked for more than 120 seconds.
16:56:09 srv kernel: [  240.112086]   Not tainted 4.2.0-27-generic
#32-Ubuntu
16:56:09 srv kernel: [  240.112124] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
16:56:09 srv kernel: [  240.112177] kworker/u8:6D 8800bfa16640
0   162  2 0x
16:56:09 srv kernel: [  240.112213] Workqueue: btrfs-extent-refs
btrfs_extent_refs_helper [btrfs]
16:56:09 srv kernel: [  240.112217]  880034f33c88 0046
81c13500 88145780
16:56:09 srv kernel: [  240.11]  0246 880034f34000
8800945b79f0 8800945b79f0
16:56:09 srv kernel: [  240.112226]  88005ddd1450 0001
880034f33ca8 817edc37
16:56:09 srv kernel: [  240.112230] Call Trace:
16:56:09 srv kernel: [  240.112239]  [] schedule+0x37/0x80
16:56:09 srv kernel: [  240.112260]  []
wait_current_trans.isra.21+0xd3/0x120 [btrfs]
16:56:09 srv kernel: [  240.112265]  [] ?
wake_atomic_t_function+0x60/0x60
16:56:09 srv kernel: [  240.112286]  []
start_transaction+0x3ac/0x570 [btrfs]
16:56:09 srv kernel: [  240.112307]  []
btrfs_join_transaction+0x17/0x20 [btrfs]
16:56:09 srv kernel: [  240.112324]  []
delayed_ref_async_start+0x18/0x90 [btrfs]
16:56:09 srv kernel: [  240.112346]  []
btrfs_scrubparity_helper+0xca/0x290 [btrfs]
16:56:09 srv kernel: [  240.112369]  []
btrfs_extent_refs_helper+0xe/0x10 [btrfs]
16:56:09 srv kernel: [  240.112374]  []
process_one_work+0x1aa/0x440
16:56:09 srv kernel: [  240.112378]  []
worker_thread+0x4b/0x4c0
16:56:09 srv kernel: [  240.112382]  [] ?
process_one_work+0x440/0x440
16:56:09 srv kernel: [  240.112386]  [] kthread+0xd8/0xf0
16:56:09 srv kernel: [  240.112390]  [] ?
kthread_create_on_node+0x1f0/0x1f0
16:56:09 srv kernel: [  240.112394]  []
ret_from_fork+0x3f/0x70
16:56:09 srv kernel: [  240.112398]  [] ?
kthread_create_on_node+0x1f0/0x1f0
16:56:09 srv kernel: [  240.112422] INFO: task mount:2323 blocked for
more than 120 seconds.
16:56:09 srv kernel: [  240.112466]   Not tainted 4.2.0-27-generic
#32-Ubuntu
16:56:09 srv kernel: [  240.112503] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
16:56:09 srv kernel: [  240.112555] mount   D 
0  2323   2076 0x
16:56:09 srv kernel: [  240.112560]  8800b709b928 0086
88145780 8800b8dd3e80
16:56:09 srv kernel: [  240.112564]  0246 8800b709c000
8800945b79f0 8800945b79f0
16:56:09 srv kernel: [  240.112568]  88005ddd1a10 0001
8800b709b948 817edc37
16:56:09 srv kernel: [  240.112573] Call Trace:
16:56:09 srv kernel: [  240.112577]  [] schedule+0x37/0x80
16:56:09 srv kernel: [  240.112597]  []
wait_current_trans.isra.21+0xd3/0x120 [btrfs]
16:56:09 srv kernel: [  240.112600]  [] ?
wake_atomic_t_function+0x60/0x60
16:56:09 srv kernel: [  240.112620]  []
start_transaction+0x3fc/0x570 [btrfs]
16:56:09 srv kernel: [  240.112639]  [] ?
btrfs_update_root+0xf0/0x340 [btrfs]
16:56:09 srv kernel: [  240.112658]  []
btrfs_start_transaction+0x1b/0x20 [btrfs]
16:56:09 srv kernel: [  240.112676]  []
btrfs_drop_snapshot+0x555/0x850 [btrfs]
16:56:09 srv kernel: [  240.112698]  []
merge_reloc_roots+0xe1/0x260 [btrfs]
16:56:09 srv kernel: [  240.112720]  []
btrfs_recover_relocation+0x38c/0x440 [btrfs]
16:56:09 srv kernel: [  240.112740]  []

Re: [PATCH] btrfs-progs: convert: show progress by default

[Jérôme Poulin]

On Fri, Feb 27, 2015 at 10:32 AM, David Sterba dste...@suse.cz wrote:

 +   printf(\t-p   show converting progress (default)\n);

A quick look a this it looks like you've added a mandatory «option»
since the case which handle -p can only turn on this flag. Logic
should be switched to -q for quiet mode instead.
--
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: Data recovery after RBD I/O error

[Jérôme Poulin]

On Mon, Jan 5, 2015 at 6:59 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
 Secondly, I would highly recommend not using ANY non-cluster-aware FS on top
 of a clustered block device like RBD


For my use-case, this is just a single server using the RBD device. No
clustering involved on the BTRFS side of thing. However, it was really
useful to take snapshots (just like LVM) before modifying the
filesystem in any way.
--
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 is related to OOM death problems on my 8GB server with both 3.15.1 and 3.14?

[Jérôme Poulin]

Hi

I'd just like to comment that I currently have the same problem, quota
are enabled, server can't stay up more than 15 days without hogging
all of its memory. Use case is a torrent server which has more read
than writes and a desktop. Kmemleak does not detect this leak after 10
days and at least 2 GB used.

On my system, only leaks found were from Nvidia and AppArmor (Ubuntu
14.04 kernel 3.13 with Nvidia proprietary driver).

On Sun, Jul 13, 2014 at 9:24 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote:

  Original Message 
 Subject: Re: btrfs is related to OOM death problems on my 8GB server with
 both 3.15.1 and 3.14?
 From: Marc MERLIN m...@merlins.org
 To: Andrew E. Mileski andr...@isoar.ca
 Date: 2014年07月13日 22:29

 On Sun, Jul 06, 2014 at 07:58:15AM -0700, Marc MERLIN wrote:

 As an update, after 1.7 days of scrubbing, the system has started
 getting sluggish, I'm getting synchronization problems/crashes in some
 of
 my tools that talk to serial ports (likely due to mini deadlocks in the
 kernel), and I'm now getting a few btrfs hangs.

 Predictably, it died yesterday afternoon after going into memory death
 (it was answering pings, but userspace was dead, and even sysrq-o did
 not respond, I had to power cycle the power outlet).

 This happened just before my 3rd scrub finished, so I'm now 2 out of 2:
 running scrub on my 3 filesystems kills the system half way through the
 3rd scrub.

 Ok, I now changed the subject line to confirm that btrfs is to blame.

 I had my system booted 6 days and it held steady at 6.4GB free.
 I mounted 2 of my 4 btrfs filesystems (one by one) and waited a few
 days, and no problems with RAM going down.

 Then I mounted my 3rd btrfs filesystem, the one that holds many files
 that has rsync backups running, and I lost 1.4GB of RAM overnight.
 I've just umounted one of its mountpoints, the one where all the backups
 happen while leaving its main pool mounted and will see if RAM keeps
 going down or not (i.e. whether the memory leak is due to rsync activity
 or some other background btrfs process).

 But generally, is there a tool to locate which kernel function allocated
 all that RAM that seems to get allocated and forgotten?

 This can be done by kernel memleak detection.
 Location:
 - Kernel hacking
 - Memory Debugging
 - Kernel memory leak detector

 Then you can check /sys/kernel/debug/memleak to see which function call
 caused the problem.

 Thanks,
 Qu


 Is /proc/slabinfo supposed to show anything useful?

 This is the filesystem in question:
 gargamel:~# btrfs fi df /mnt/btrfs_pool2/
 Data, single: total=3.34TiB, used=3.32TiB
 System, DUP: total=8.00MiB, used=400.00KiB
 System, single: total=4.00MiB, used=0.00
 Metadata, DUP: total=77.50GiB, used=59.87GiB
 Metadata, single: total=8.00MiB, used=0.00


 Thanks,
 Marc


 --
 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: Is btrfs related to OOM death problems on my 8GB server with both 3.15.1 and 3.14?

[Jérôme Poulin]

Hi,

For this same problem I once got into single user after 2 weeks of
utilisation and killed all, umounted all FS except root which is ext4,
rmmod'ed all modules and see by yourself:
http://i39.tinypic.com/2rrrjtl.jpg

For those who want it textually:
15 days uptime
10 user mode processes (systemd, top and bash)
2 GB memory usage, 4 GB total memory, 17 MB cache, 32 KB buffers.

On Sun, Jul 6, 2014 at 10:58 AM, Marc MERLIN m...@merlins.org wrote:
 On Sat, Jul 05, 2014 at 07:43:18AM -0700, Marc MERLIN wrote:
 On Sat, Jul 05, 2014 at 09:47:09AM -0400, Andrew E. Mileski wrote:
  On 2014-07-03 9:19 PM, Marc MERLIN wrote:
  I upgraded my server from 3.14 to 3.15.1 last week, and since then it's 
  been
  running out of memory and deadlocking (panic= doesn't even work).
  I downgraded back to 3.14, but I already had the problem once since then.
 
  I didn't see any mention of the btrfs utility version in this thread
  (I may be blind though).
 
  My server was suffering from frequent panics upon scrub / defrag /
  balance, until I updated the btrfs utility.  That resolved all my
  issues.

 Really? The userland tool should only send ioctls to the kernel, I
 really can't see how it would cause the kernel code to panic or not.

 gargamel:~# btrfs --version
 Btrfs v3.14.1
 which is the latest in debian unstable.

 As an update, after 1.7 days of scrubbing, the system has started
 getting sluggish, I'm getting synchronization problems/crashes in some of
 my tools that talk to serial ports (likely due to mini deadlocks in the
 kernel), and I'm now getting a few btrfs hangs.

 Predictably, it died yesterday afternoon after going into memory death
 (it was answering pings, but userspace was dead, and even sysrq-o did
 not respond, I had to power cycle the power outlet).

 This happened just before my 3rd scrub finished, so I'm now 2 out of 2:
 running scrub on my 3 filesystems kills the system half way through the
 3rd scrub.

 This is the last memory log that reached the disk:
 http://marc.merlins.org/tmp/btrfs-oom2.txt

 Do those logs point to any possible culprit, or a kernel memory leak
 cannot be pointed to its source because the kernel loses track of who
 requested the memory that leaked?


 Excerpt here:
 Sat Jul  5 14:25:04 PDT 2014
  total   used   free sharedbuffers cached
 Mem:   78947927712384 182408  0 28 227480
 -/+ buffers/cache:7484876 409916
 Swap: 15616764 463732   15153032

 Userspace is using 345MB according to ps

 Sat Jul  5 14:25:04 PDT 2014
 MemTotal:7894792 kB
 MemFree:  184556 kB
 MemAvailable: 269568 kB
 Buffers:  28 kB
 Cached:   228164 kB
 SwapCached:18296 kB
 Active:   178196 kB
 Inactive: 187016 kB
 Active(anon):  70068 kB
 Inactive(anon):71100 kB
 Active(file): 108128 kB
 Inactive(file):   115916 kB
 Unevictable:5624 kB
 Mlocked:5624 kB
 SwapTotal:  15616764 kB
 SwapFree:   15152768 kB
 Dirty: 17716 kB
 Writeback:   516 kB
 AnonPages:140588 kB
 Mapped:21940 kB
 Shmem:   688 kB
 Slab: 181708 kB
 SReclaimable:  59808 kB
 SUnreclaim:   121900 kB
 KernelStack:4728 kB
 PageTables: 8480 kB
 NFS_Unstable:  0 kB
 Bounce:0 kB
 WritebackTmp:  0 kB
 CommitLimit:19564160 kB
 Committed_AS:1633204 kB
 VmallocTotal:   34359738367 kB
 VmallocUsed:  358996 kB
 VmallocChunk:   34359281468 kB
 HardwareCorrupted: 0 kB
 AnonHugePages: 0 kB
 HugePages_Total:   0
 HugePages_Free:0
 HugePages_Rsvd:0
 HugePages_Surp:0
 Hugepagesize:   2048 kB
 DirectMap4k:  144920 kB
 DirectMap2M: 7942144 kB

 Thanks,
 Marc
 --
 A mouse is a device used to point at the xterm you want to type in - A.S.R.
 Microsoft is to operating systems 
    what McDonalds is to gourmet 
 cooking
 Home page: http://marc.merlins.org/ | PGP 
 1024R/763BE901
 --
 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: memory leak in =3.11.6

[Jérôme Poulin]

On Tue, Oct 29, 2013 at 12:42 PM, Duncan 1i5t5.dun...@cox.net wrote:

 So I'd call the qgroups feature broken at this time

I agree. I made a page about Quotas on the wiki so to document my
findings as documentation is really sparse. If you consult the section
Known issues, you will find those:

* To get accurate information, you must issue a sync before using the
qgroup show command.
* The qgroup show command is missing some information, for example you
cannot see which subvolume is part of a parent qgroup.
* Creating a qgroup from an existing directory will show a 0 usage
until a full filesystem quota rescan is issued.
* Using btrfs subvolume delete will break qgroup unshared space usage.
* After deleting a subvolume, you must manually delete the associated qgroup.

Knowing this, if you create a qgroup after some files have been added
to a subvolume, those never get accounted for until you rescan the
whole volume. This means that if you manage to delete enough not
accounted for files, you get negative numbers.

Wiki: https://btrfs.wiki.kernel.org/index.php/Quota_support
--
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: memory leak in =3.11.6

[Jérôme Poulin]

On Mon, Oct 28, 2013 at 6:34 PM, Kai Krakow hurikhan77+bt...@gmail.com wrote:

 If I close all my desktop programs, my system stays at +12 GB RAM usage
 while after a fresh boot it has 12+ GB free (of 16 GB). Cache stays low at 2
 GB while after a few minutes uptime cache is about 5 GB.

I probably have the same problem over here, after about 2 weeks of
random read/write it seems my memory and swap get almost full and even
after killing all process and getting in single user mode, memory
won't free up.  Would you happen to have quota enabled too? Kernel is
3.11.4
--
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: rootfs crash

[Jérôme Poulin]

On Mon, Sep 16, 2013 at 6:48 AM, Jogi Hofmüller j...@mur.at wrote:
  After btrfs-zero-log the device
 was still not mountable.  Mount attempts fail with i/o erros now.
...
 All this is happening on an Asus Zen book  UX32V with two 128GB SSDs.


Did you make sure you aren't working with a dead SSD? That would make
everything much more complicated than it should be. I also had a
Zenbook from Asus with SSD with Btrfs, and it died 2 months ago. It
couldn't handle Btrfs for more than 6 months. Either those SSDs are
weak or Btrfs really is an SSD killer even though it is a COW FS.

Maybe using ddrescue first to get it off the defective media would
give you a chance to recover more data.
--
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: Heavy memory leak when using quota groups

[Jérôme Poulin]

I'm pretty I encountered the same leak over here, 15 days uptime and I
had consistent out of memory problems, I got angry and did go in
single user mode and noticed that with only systemd-screen-bash(2) I
had 2 GB of memory used on 4 GB total. This box mostly has random
reads and just before the out of memory condition had 12 GB written to
a lot of files.

# btrfs qgroup show /mnt/btrfs
0/337 13953818624 9494970368
0/338 0 0
0/353 20934205440 20934205440
0/373 36420952064 36420952064
0/668 0 19161088
0/669 21279420416 16839733248
0/890 -97652736 -97652736
0/907 65536 65536
0/910 0 0

Screenshot of top/processes/memory: http://i39.tinypic.com/2rrrjtl.jpg

On Wed, Aug 7, 2013 at 4:00 AM, Tomasz Chmielewski man...@wpkg.org wrote:
 On Wed, 7 Aug 2013 00:42:27 +0800
 Tomasz Chmielewski man...@wpkg.org wrote:

  What do I have to do to reproduce it here? How do you generate the
  load? What is the disk setup, what the qgroups setup?

 Unfortunately I don't have a way to reproduce, as the issue
 happened to me only once.

 I keep removing the files, and memory usage has grown to 28 GB (out of
 32 GB).

 Is there anything I can debug at this point?

 # free
  total   used   free sharedbuffers cached
 Mem:  32638512   32476992 161520  0732 3531152
 -/+ buffers/cache:   289451083693404
 Swap: 16776116 173392   16602724


 # cat /proc/meminfo
 MemTotal:   32638512 kB
 MemFree:  163364 kB
 Buffers: 864 kB
 Cached:  3531940 kB
 SwapCached:60992 kB
 Active:  3599804 kB
 Inactive:2422176 kB
 Active(anon):1860412 kB
 Inactive(anon):   629848 kB
 Active(file):1739392 kB
 Inactive(file):  1792328 kB
 Unevictable:   0 kB
 Mlocked:   0 kB
 SwapTotal:  16776116 kB
 SwapFree:   16602916 kB
 Dirty: 85432 kB
 Writeback: 10320 kB
 AnonPages:   2458792 kB
 Mapped:11068 kB
 Shmem:   796 kB
 Slab:3168820 kB
 SReclaimable:3099388 kB
 SUnreclaim:69432 kB
 KernelStack:3408 kB
 PageTables:14764 kB
 NFS_Unstable:  0 kB
 Bounce:0 kB
 WritebackTmp:  0 kB
 CommitLimit:33095372 kB
 Committed_AS:4301988 kB
 VmallocTotal:   34359738367 kB
 VmallocUsed:  130036 kB
 VmallocChunk:   34359595900 kB
 HardwareCorrupted: 0 kB
 HugePages_Total:   0
 HugePages_Free:0
 HugePages_Rsvd:0
 HugePages_Surp:0
 Hugepagesize:   2048 kB
 DirectMap4k:   12520 kB
 DirectMap2M:33220608 kB

 --
 Tomasz Chmielewski
 http://wpkg.org
 --
 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: query btrfs creation options

[Jérôme Poulin]

I think actual userland tools should be able to do what you want;
leafsize, nodesize, sectorsize: btrfs-show-super /dev/dm-6
label: blkid /dev/dm-6
data, metadata: btrfs filesystem df /

# btrfs-show-super /dev/dm-6
superblock: bytenr=65536, device=/dev/dm-6
-
csum 0xba41e65b [match]
bytenr 65536
flags 0x1
magic _BHRfS_M [match]
fsid 456e363c-650e-4c29-898c-b2b65bf9c3b3
label p4-btrfs2
generation 253003
root 664749473792
sys_array_size 97
chunk_root_generation 218142
root_level 1
chunk_root 131072
chunk_root_level 0
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 536869732352
bytes_used 441861300224
sectorsize 4096
nodesize 65536
leafsize 65536
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x29
csum_type 0
csum_size 4
cache_generation 253003
dev_item.uuid 5a5802fb-5012-4bae-897e-388754b5ed08
dev_item.fsid 456e363c-650e-4c29-898c-b2b65bf9c3b3 [match]
dev_item.type 0
dev_item.total_bytes 536869732352
dev_item.bytes_used 446689181696
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0


On Wed, Apr 24, 2013 at 4:00 PM, Rich Turner rtur...@storix.com wrote:
 i am looking for a way to query btrfs filesystems for all options used to
 create the filesystem (i.e. data, leafsize, label, metadata, nodesize,
 sectorsize) in an effort to be able to record this information and be able
 to recreate the filesystem with the same attributes if necessary.

 i see there is a feature request for creating an api/library that may
 provide this functionality, but i am unable to find any suitable userspace
 command that provides the information.
 --
 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 and the steadily lit LED

[Jérôme Poulin]

On Wed, Mar 27, 2013 at 4:56 AM, Swâmi Petaramesh sw...@petaramesh.org wrote:
 After having received strong advice from the people in this list to
 upgrade my kernel to the latest one, I have installed 3.8.0-14-generic
 #24-Ubuntu SMP x86_64 on several (4) machines.

 In the hope of improving systems speed I had also removed all snapshots
 then defragged the FSes - the snapshots have been recreated since, as I
 use the excellent SuSE Snapper tool.

 But well, all 4 machines are still slow like hell. All of them are used
 for quite basic daily tasks - web browsing, email, typical LibreOffice
 tasks, nothing very mysterious there, no specific heavy DB work.

 All machines have 64-bits Linuxes (either Ubuntu 12.10 or 13.04ß), with
 decent amounts of RAM - 2 GB to 4 GB - and disks filled less than 75%

 With such a setup, I would expect any decent filesystem to deliver
 excellent performance. Still, all of my machines are slow like hell and
 I'm most of the time in mode « Working my patience while waiting for the
 HD LED to go off ».

 I haven't noticed any real-life noticeable improvement upgrading the
 kernels from 3.5.x to 3.8.x

 So I'm wondering...

I must say after having used BTRFS for quite some time on many
different desktop systems that this pretty much summaries my though of
BTRFS used on a desktop system.

I have been using it on my root filesystem for 5 consecutive systems
and all of them were I/O bound most of the time after 2 months of
normal usage with or *without* snapshots. Defragging or rebalancing
doesn't help, growing leaf size helps push back the problem, but it
eventually come back.

The only way to get around the problem is to re-format the drive and
restore from backups. I'm pretty sure I toasted 2 SSDs because of
BTRFS, one in 4 months, the other in 6 months. 80 GB SSDs, I switched
this system to NILFS2 for now, which isn't I/O bound and doesn't kill
flash drives.

A bigger system that I administer has 14 TB worth of data and has
constant loads of 6 to 8 (4 CPUs), mostly because of I/O wait just
because it unzips a file. This system never had a snapshot.

On the system I'm writing, watching a YouTube video will hang one
second every 30 seconds because flash player writes the video to /tmp.

I submitted some backtrace but lost hope, I used kernel from 3.0 to
3.9-rc4 with the FS, features are great, it is great for a file
server, but for desktop, it is really hard to use as root or /home
because of this issue.

Is there any data I can submit to help enhance performance on a desktop system?
--
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: Debian 3.7.1 BTRFS crash

[Jérôme Poulin]

On Tue, Mar 12, 2013 at 10:03 PM, Eric Sandeen sand...@redhat.com wrote:
 [   37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143: IO 
 failure
 [   37.176791] btrfs is forced readonly
 [   37.176793] btrfs: run_one_delayed_ref returned -5



It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
2 months for each. ddrescue'ing the SSD would probably give better
chances of recovery and give BTRFS/btrfsck a chance to write correctly
to the newly copied image.
--
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: mkfs.btrfs broken

[Jérôme Poulin]

On Thu, Mar 7, 2013 at 10:21 AM, Swâmi Petaramesh sw...@petaramesh.org wrote:
 lstat64(/sqfs_disk, 0xbff57820)   = -1 ENOENT (No such file or
 directory)

mkfs.btrfs tries to lookup loop devices by their filenames and fails
if any loop device file is missing.
--
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: Kernel panic when scrub is used

[Jérôme Poulin]

On Wed, Feb 20, 2013 at 1:42 PM, Jérôme Poulin jeromepou...@gmail.com wrote:
 On Wed, Feb 20, 2013 at 8:11 AM, David Sterba dste...@suse.cz wrote:
 Was the filesystem created with nodesize  4k ?

 Yes; 64KB.

I just noticed I didn't mention that I have raid5/6 code merged in but
it never was used on the partition I scrubbed.
--
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: Kernel panic when scrub is used

[Jérôme Poulin]

Here you go, I also added 2 other screenshots of the same problem.
http://tinypic.com/r/5ckgug/6
http://tinypic.com/r/t0i9t4/6
http://tinypic.com/r/2r3xdvl/6

On Mon, Feb 18, 2013 at 12:37 PM, Arne Jansen li...@die-jansens.de wrote:
 On 02/18/13 18:14, Jérôme Poulin wrote:
 I experience a kernel panic with General protection fault when doing
 a scrub on Kernel 3.8-rc7.

 Here is a screenshot: http://tinypic.com/r/34r6nad/6

 I'd love to see the first stacktrace...


 The weird part is that the scrub completes from initramfs, but when
 system is fully booted, is kernel panics every time in the low
 percentage. (10%)
 --
 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: kernel BUG at fs/btrfs/extent-tree.c:6185!

[Jérôme Poulin]

 I was however able to save my data with btrfs-restore command (it boots into
 some systemd emergency shell or I can use recovery cd). I tried to mount it
 manually and after no success (the mount command does not end) mount it with
 -o recovery option, but it does not do anything nether (well the command is
 'running' for hours without any output until I turn the pc off, so I do not 
 know
 wheather it is recovering something or not). So before doing any btrfsck
 --repair or btrfs-zero-log (which are pretty much all commands for
 'repairing' btrfs I founded over the net) I would like to ask for some help
 or advices.

I recently encountered the same problem on kernel 3.8 with Archlinux,
I'm running BTRFS in RAID1 and had pretty much the same problem.
Mounting the volume resulted in this trace and no mount, trying to
mount again would freeze and I would need to reboot to try again, I
tried using clear_cache, recovery, ro without any success, tried
btrsck --repair, it said it fixed something but fails to mount
afterward and furthermore complains about space_cache being outdated.

I had to use btrfs-zero-log before it could mount again.

Here is the trace I had:

[   15.289140] device label p4-btrfs devid 1 transid 545533 /dev/dm-1
[   15.336323] device label p4-openwrt devid 1 transid 56491 /dev/dm-2
[   15.622376] device label p4-btrfsRoot devid 3 transid 128743 /dev/sdc4
[   15.683499] btrfs: force clearing of disk cache
[   15.697295] btrfs: disk space caching is enabled
[   16.864388] [ cut here ]
[   16.877759] kernel BUG at fs/btrfs/free-space-cache.c:1542!
[   16.891417] invalid opcode:  [#1] PREEMPT SMP
[   16.905434] Modules linked in: dm_crypt sr_mod cdrom sd_mod
ata_generic pata_acpi hid_generic crc32c_intel ghash_clmulni_intel
aesni_intel aes_x86_64 ablk_helper cryptd xts lrw gf128mul ahci
sata_mv libahci pata_jmicron ehci_pci xhci_hcd uhci_hcd ata_piix
libata btrfs crc32c libcrc32c zlib_deflate ext4 crc16 jbd2 mbcache
fuse usbhid hid usb_storage scsi_mod ehci_hcd usbcore usb_common
raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor
async_tx raid1 md_mod dm_snapshot dm_mod loop
[   17.024301] CPU 0
[   17.024553] Pid: 216, comm: mount Not tainted
3.8.0-rc5-TiARCH-4-g99beec4-dirty #3 Gigabyte Technology Co., Ltd.
P55-USB3/P55-USB3
[   17.080278] RIP: 0010:[a02bbfbf]  [a02bbfbf]
remove_from_bitmap+0x16f/0x180 [btrfs]
[   17.118802] RSP: 0018:88011567f6e8  EFLAGS: 00010287
[   17.138121] RAX:  RBX: 88011769cf80 RCX: 880118e053a4
[   17.157722] RDX: 0001b0b22000 RSI: 8000 RDI: 6200
[   17.177096] RBP: 88011567f738 R08: 880114c7d3c8 R09: 1e00
[   17.196438] R10: ea0004500d80 R11: a0267948 R12: 88011567f760
[   17.216040] R13: 88011567f758 R14: 880118e05380 R15: 0001b6e5
[   17.235653] FS:  7f7f55594780() GS:88011fc0()
knlGS:
[   17.274869] CS:  0010 DS:  ES:  CR0: 80050033
[   17.294723] CR2: 01dc9008 CR3: 000118fa2000 CR4: 07f0
[   17.314910] DR0:  DR1:  DR2: 
[   17.334664] DR3:  DR6: 0ff0 DR7: 0400
[   17.353846] Process mount (pid: 216, threadinfo 88011567e000,
task 8801154beb40)
[   17.392013] Stack:
[   17.410836]  880114036600 880118e053a4 0001b0bce000
000a4000
[   17.449642]  88011567f738 880118e05380 880118e053a4

[   17.488869]  880118cf0200 880115a95000 88011567f788
a02be2d3
[   17.527977] Call Trace:
[   17.546721]  [a02be2d3] btrfs_remove_free_space+0x53/0x290 [btrfs]
[   17.565962]  [a026f80f]
btrfs_alloc_logged_file_extent+0x1bf/0x1e0 [btrfs]
[   17.603515]  [a025b32a] ? btrfs_free_path+0x2a/0x40 [btrfs]
[   17.622918]  [a02b6e90] replay_one_extent+0x620/0x690 [btrfs]
[   17.641943]  [a0290604] ? btrfs_destroy_inode+0x1c4/0x2e0 [btrfs]
[   17.660666]  [a02a04f3] ? read_extent_buffer+0xc3/0x120 [btrfs]
[   17.679065]  [a02b7f1b] replay_one_buffer+0x2db/0x3a0 [btrfs]
[   17.697334]  [a029eded] ? alloc_extent_buffer+0x9d/0x490 [btrfs]
[   17.715505]  [a02b48e2] walk_down_log_tree+0x212/0x400 [btrfs]
[   17.733741]  [a02b4b6d] walk_log_tree+0x9d/0x1f0 [btrfs]
[   17.751879]  [a02bb41b] btrfs_recover_log_trees+0x21b/0x3a0 [btrfs]
[   17.770168]  [a02b7c40] ? replay_one_dir_item+0xf0/0xf0 [btrfs]
[   17.788456]  [a027f45f] open_ctree+0x166f/0x1d00 [btrfs]
[   17.806537]  [81256ff1] ? disk_name+0x61/0xc0
[   17.824153]  [a0257b83] btrfs_mount+0x633/0x770 [btrfs]
[   17.841672]  [81168f38] ? alloc_pages_current+0xb8/0x180
[   17.859027]  [8118dfb3] mount_fs+0x43/0x1b0
[   17.876427]  [811a8c54] vfs_kern_mount+0x74/0x110
[   17.894093]  

Re: Weird Warning

[Jérôme Poulin]

Tried with cmason 3.6.0 for-linus tree. Did a find on the BTRFS.

[  152.846595] [ cut here ]
[  152.848841] kernel BUG at fs/btrfs/extent-tree.c:1519!
[  152.848841] invalid opcode:  [#1] SMP
[  152.848841] Modules linked in:
[  152.848841] CPU 0
[  152.848841] Pid: 1256, comm: btrfs-transacti Not tainted 3.6.0+ #3
Bochs Bochs
[  152.848841] RIP: 0010:[811bc1a8]  [811bc1a8]
lookup_inline_extent_backref+0x4c8/0x500
[  152.848841] RSP: 0018:880014987a20  EFLAGS: 00010246
[  152.848841] RAX: 0020 RBX: 880016d65580 RCX: 880016bcc000
[  152.848841] RDX: 2000 RSI: 880017ffd000 RDI: 880016d65580
[  152.848841] RBP: 00b2 R08: 2f94 R09: 8800149879e0
[  152.848841] R10:  R11: 0002 R12: 2fb1
[  152.848841] R13: 2f17 R14: 880016c6b090 R15: 2f94
[  152.848841] FS:  () GS:880017c0()
knlGS:
[  152.848841] CS:  0010 DS:  ES:  CR0: 8005003b
[  152.848841] CR2: ff600400 CR3: 164c2000 CR4: 06b0
[  152.848841] DR0:  DR1:  DR2: 
[  152.848841] DR3:  DR6: 0ff0 DR7: 0400
[  152.848841] Process btrfs-transacti (pid: 1256, threadinfo
880014986000, task 88001496c580)
[  152.848841] Stack:
[  152.848841]  3f9b 811aca93 
1000
[  152.848841]  880016417800 0035 
12f22000
[  152.848841]  880014987b40 880016de20b8 
00ff812150bd
[  152.848841] Call Trace:
[  152.848841]  [811aca93] ? leaf_space_used+0x113/0x160
[  152.848841]  [811bee9d] ? __btrfs_free_extent+0xcd/0x890
[  152.848841]  [8121595a] ? btrfs_merge_delayed_refs+0x21a/0x2f0
[  152.848841]  [811c32b7] ? run_clustered_refs+0x307/0xa90
[  152.848841]  [81205bee] ? btrfs_tree_unlock+0x1e/0xc0
[  152.848841]  [811c691a] ? btrfs_run_delayed_refs+0xca/0x2f0
[  152.848841]  [811c6c9f] ?
btrfs_write_dirty_block_groups+0x15f/0x5f0
[  152.848841]  [815475fc] ? commit_cowonly_roots+0x127/0x1e8
[  152.848841]  [811d6c3e] ? btrfs_commit_transaction+0x54e/0xa50
[  152.848841]  [81054210] ? abort_exclusive_wait+0xb0/0xb0
[  152.848841]  [811d7628] ? start_transaction+0x78/0x390
[  152.848841]  [81044130] ? usleep_range+0x40/0x40
[  152.848841]  [811ce755] ? transaction_kthread+0x1a5/0x1d0
[  152.848841]  [811ce5b0] ? cleaner_kthread+0xd0/0xd0
[  152.848841]  [810538c5] ? kthread+0x85/0x90
[  152.848841]  [8154d504] ? kernel_thread_helper+0x4/0x10
[  152.848841]  [81053840] ? kthread_worker_fn+0x110/0x110
[  152.848841]  [8154d500] ? gs_change+0x13/0x13
[  152.848841] Code: ff 4d 89 f7 31 c0 4c 8b 74 24 48 e9 78 ff ff ff
0f 1f 00 b8 0d 00 00 00 e9 32 fd ff ff 66 0f 1f 44 00 00 a8 01 0f 85
dc fc ff ff 0f 0b 66 0f 1f 44 00 00 c7 44 24 1c 0d 00 00 00 e9 9e fb
ff ff
[  152.848841] RIP  [811bc1a8]
lookup_inline_extent_backref+0x4c8/0x500
[  152.848841]  RSP 880014987a20
[  152.950405] ---[ end trace b34b153b89ec3692 ]---

On Fri, Oct 19, 2012 at 6:13 PM, cwillu cwi...@cwillu.com wrote:
 On Fri, Oct 19, 2012 at 3:51 PM, Jérôme Poulin jeromepou...@gmail.com wrote:
 After updating to 3.5.5, I get thi on boot and listing some dir freezes.
 I don't have anything important on that volume but I'm willing to
 debug the problem if needed.  Would I need a more recent kernel?

 Probably worth trying 3.7-rc1, or at least cmason's for-linus (which
 is 3.6.0 + the btrfs changes that went into 3.7).
--
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: Weird Warning

[Jérôme Poulin]

Here is an excerpt of btrfsck:

# ./btrfsck /dev/nbd1
checking extents
corrupt extent record: key 314454016 168 524288
corrupt extent record: key 314978304 168 524288
corrupt extent record: key 315502592 168 524288
corrupt extent record: key 316026880 168 524288
corrupt extent record: key 316551168 168 524288
corrupt extent record: key 317075456 168 409600
corrupt extent record: key 317485056 168 372736
corrupt extent record: key 317857792 168 65536
corrupt extent record: key 317960192 168 1081344
ref mismatch on [289406976 36864] extent item 1, found 0
Incorrect local backref count on 289406976 root 257 owner
18446744073709551604 offset 0 found 0 wanted 1 back 0x2604be0
backpointer mismatch on [289406976 36864]
owner ref check failed [289406976 36864]
ref mismatch on [289443840 36864] extent item 1, found 0
Incorrect local backref count on 289443840 root 259 owner
18446744073709551604 offset 0 found 0 wanted 1 back 0x2604cc0
backpointer mismatch on [289443840 36864]
owner ref check failed [289443840 36864]
ref mismatch on [304230400 262144] extent item 1, found 0
Incorrect local backref count on 304230400 root 259 owner 261 offset
262144 found 0 wanted 1 back 0x2604da0
backpointer mismatch on [304230400 262144]
owner ref check failed [304230400 262144]
ref mismatch on [304492544 524288] extent item 1, found 0
Incorrect local backref count on 304492544 root 259 owner 261 offset
524288 found 0 wanted 1 back 0x2604e80
backpointer mismatch on [304492544 524288]
owner ref check failed [304492544 524288]
ref mismatch on [305016832 524288] extent item 1, found 0
Incorrect local backref count on 305016832 root 259 owner 261 offset
1048576 found 0 wanted 1 back 0x2604f60
backpointer mismatch on [305016832 524288]
owner ref check failed [305016832 524288]
ref mismatch on [305541120 524288] extent item 1, found 0
Incorrect local backref count on 305541120 root 259 owner 261 offset
1572864 found 0 wanted 1 back 0x2605040
backpointer mismatch on [305541120 524288]
owner ref check failed [305541120 524288]
ref mismatch on [313929728 524288] extent item 65536, found 1
ref mismatch on [314454016 524288] extent item 65536, found 1
Backref 314454016 root 259 owner 261 offset 10485760 num_refs 0 not
found in extent tree
Incorrect local backref count on 314454016 root 259 owner 261 offset
10485760 found 1 wanted 0 back 0x2600010
backpointer mismatch on [314454016 524288]
ref mismatch on [314978304 524288] extent item 65536, found 1
Backref 314978304 root 259 owner 261 offset 11010048 num_refs 0 not
found in extent tree
Incorrect local backref count on 314978304 root 259 owner 261 offset
11010048 found 1 wanted 0 back 0x26000f0
backpointer mismatch on [314978304 524288]
ref mismatch on [315502592 524288] extent item 281474976776192, found 1
Backref 315502592 root 259 owner 261 offset 11534336 num_refs 0 not
found in extent tree
Incorrect local backref count on 315502592 root 259 owner 261 offset
11534336 found 1 wanted 0 back 0x26001d0
backpointer mismatch on [315502592 524288]
ref mismatch on [316026880 524288] extent item 4294967296, found 1
Backref 316026880 root 259 owner 261 offset 12058624 num_refs 0 not
found in extent tree
Incorrect local backref count on 316026880 root 259 owner 261 offset
12058624 found 1 wanted 0 back 0x26002b0
backpointer mismatch on [316026880 524288]
ref mismatch on [316551168 524288] extent item 4294967296, found 1
Backref 316551168 root 259 owner 261 offset 12582912 num_refs 0 not
found in extent tree
Incorrect local backref count on 316551168 root 259 owner 261 offset
12582912 found 1 wanted 0 back 0x2600390
backpointer mismatch on [316551168 524288]
ref mismatch on [317075456 409600] extent item 4294967297, found 1
Backref 317075456 root 259 owner 261 offset 13107200 num_refs 0 not
found in extent tree
Incorrect local backref count on 317075456 root 259 owner 261 offset
13107200 found 1 wanted 0 back 0x2600470
backpointer mismatch on [317075456 409600]
ref mismatch on [317485056 372736] extent item 4294967296, found 1
Backref 317485056 root 259 owner 262 offset 0 num_refs 0 not found in
extent tree
Incorrect local backref count on 317485056 root 259 owner 262 offset 0
found 1 wanted 0 back 0x2600550
backpointer mismatch on [317485056 372736]
ref mismatch on [317857792 65536] extent item 4294967296, found 1
Backref 317857792 root 1 owner 258 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 317857792 root 1 owner 258 offset 0
found 1 wanted 0 back 0x2604b00
backpointer mismatch on [317857792 65536]
ref mismatch on [317960192 1081344] extent item 4294967296, found 1
Backref 317960192 root 259 owner 262 offset 368640 num_refs 0 not
found in extent tree
Incorrect local backref count on 317960192 root 259 owner 262 offset
368640 found 1 wanted 0 back 0x2600630
backpointer mismatch on [317960192 1081344]
ref mismatch on [539897856 8796093022208] extent item 0, found 1
Backref 539897856 root 259 owner 261 offset 18374686479673196544
num_refs 0 not found in extent tree

Re: Weird Warning

[Jérôme Poulin]

After updating to 3.5.5, I get thi on boot and listing some dir freezes.
I don't have anything important on that volume but I'm willing to
debug the problem if needed.  Would I need a more recent kernel?

[  128.574596] [ cut here ]
[  128.574652] kernel BUG at
/home/blank/debian/kernel/release/linux/linux-3.5.5/fs/btrfs/extent-tree.c:1516!
[  128.574715] invalid opcode:  [#1] SMP
[  128.574853] CPU 3
[  128.574901] Modules linked in: nfsd nfs nfs_acl auth_rpcgss fscache
lockd sunrpc loop coretemp snd_pcm kvm_intel snd_page_alloc snd_timer
kvm snd crc32c_intel soundcore iTCO_wdt iTCO_vendor_support microcode
dcdbas i7core_edac pcspkr lpc_ich mfd_core edac_core evdev button
acpi_power_meter processor thermal_sys ext4 crc16 jbd2 mbcache btrfs
crc32c libcrc32c zlib_deflate raid456 async_raid6_recov async_memcpy
async_pq async_xor xor async_tx raid6_pq raid1 ohci_hcd uhci_hcd
sd_mod crc_t10dif dm_mod md_mod hid_generic usbhid hid sg sr_mod cdrom
ehci_hcd ahci libahci mpt2sas raid_class scsi_transport_sas bnx2
usbcore usb_common libata scsi_mod igb dca [last unloaded:
scsi_wait_scan]
[  128.578404]
[  128.578449] Pid: 1995, comm: btrfs-transacti Not tainted
3.5-trunk-amd64 #1 Debian 3.5.5-1~experimental.1 Dell Inc. PowerEdge
R310/05XKKK
[  128.578647] RIP: 0010:[a0200309]  [a0200309]
lookup_inline_extent_backref+0x17e/0x377 [btrfs]
[  128.578766] RSP: 0018:880138c8d9b0  EFLAGS: 00010246
[  128.578820] RAX: 0020 RBX: 880134878880 RCX: 2f7c
[  128.578890] RDX: 2ee2 RSI: 2f57 RDI: 88013ae309c8
[  128.578961] RBP: 2f5f R08:  R09: 880138c8d970
[  128.579031] R10: 0008 R11: 0002 R12: 88013ae309c8
[  128.579101] R13: 00b2 R14: 0035 R15: 
[  128.579172] FS:  () GS:88013f26()
knlGS:
[  128.579258] CS:  0010 DS:  ES:  CR0: 8005003b
[  128.579326] CR2: 02139108 CR3: 0160b000 CR4: 07e0
[  128.579397] DR0:  DR1:  DR2: 
[  128.579467] DR3:  DR6: 0ff0 DR7: 0400
[  128.579538] Process btrfs-transacti (pid: 1995, threadinfo
880138c8c000, task 880138e76800)
[  128.579625] Stack:
[  128.579686]  2ee2 2f47 8801348495a0
0035005e
[  128.579947]  3ae309c8 8801394fd400 2f7c
12f22000
[  128.580249]  a800c2b0 880138c8dae8 88013592c500
8050
[  128.580509] Call Trace:
[  128.580581]  [a0201f50] ? __btrfs_free_extent+0xc6/0x5bd [btrfs]
[  128.580659]  [a0201e5a] ?
alloc_reserved_file_extent+0x1e5/0x215 [btrfs]
[  128.580753]  [a020579b] ? run_clustered_refs+0x6f0/0x77d [btrfs]
[  128.580832]  [a020578a] ? run_clustered_refs+0x6df/0x77d [btrfs]
[  128.580917]  [a022591c] ?
btrfs_set_token_inode_flags+0x70/0xbe [btrfs]
[  128.581004]  [810c380a] ? __set_page_dirty_nobuffers+0x16/0xd8
[  128.581083]  [a0205a32] ?
btrfs_run_delayed_refs+0x20a/0x302 [btrfs]
[  128.581177]  [a0205dd3] ?
btrfs_write_dirty_block_groups+0x2a9/0x497 [btrfs]
[  128.581269]  [a0258ce3] ? commit_cowonly_roots+0x107/0x1cd [btrfs]
[  128.581342]  [8105a823] ? should_resched+0x5/0x23
[  128.581421]  [a02135f7] ?
btrfs_commit_transaction+0x429/0x8ae [btrfs]
[  128.581508]  [81054a7f] ? add_wait_queue+0x3c/0x3c
[  128.581587]  [a0213f29] ? start_transaction+0x256/0x2ae [btrfs]
[  128.581659]  [810467c0] ? usleep_range+0x3e/0x3e
[  128.581728]  [8105a823] ? should_resched+0x5/0x23
[  128.581806]  [a020e086] ? transaction_kthread+0x15e/0x21b [btrfs]
[  128.581878]  [81360f00] ? __schedule+0x4c6/0x4e0
[  128.581956]  [a020df28] ? try_to_freeze+0x2e/0x2e [btrfs]
[  128.582035]  [a020df28] ? try_to_freeze+0x2e/0x2e [btrfs]
[  128.582106]  [81054435] ? kthread+0x67/0x6f
[  128.582174]  [81367da4] ? kernel_thread_helper+0x4/0x10
[  128.582245]  [810543ce] ? kthread_freezable_should_stop+0x3c/0x3c
[  128.582316]  [81367da0] ? gs_change+0x13/0x13
[  128.582383] Code: 48 8b 4c 24 08 48 8b 14 24 4c 01 f1 a8 02 48 8d
6a 7d 48 89 4c 24 30 74 0e 48 8d aa 8f 00 00 00 48 39 cd 76 08 0f 0b
a8 01 75 02 0f 0b 48 3b 6c 24 30 72 22 41 bc fe ff ff ff 0f 86 42 01
00 00
[  128.585347] RIP  [a0200309]
lookup_inline_extent_backref+0x17e/0x377 [btrfs]
[  128.585484]  RSP 880138c8d9b0
[  128.585561] ---[ end trace 5b4742b10c0f008c ]---


On Fri, Oct 19, 2012 at 4:58 PM, cwillu cwi...@cwillu.com wrote:
 On Fri, Oct 19, 2012 at 2:54 PM, Jérôme Poulin jeromepou...@gmail.com wrote:
 I've got this weird WARNING in my system log on a freshly created FS,
 I'm using ACL with Samba, this is the only difference I could tell
 from any other

Re: Out of memory condition

[Jérôme Poulin]

Right now, with the patches applied on 3.5.0, Chrome didn't freeze
under out of memory conditions (2 OOM killer invocation).

On Fri, Oct 5, 2012 at 4:44 PM, Josef Bacik jba...@fusionio.com wrote:
 On Fri, Oct 05, 2012 at 02:23:25PM -0600, Jérôme Poulin wrote:
 I guess I'll be the guy who will test out of memory conditions! Here's
 another stack further down the code.


 Ok that was just a warning, did the box keep going after that?  I've fixed it 
 up
 and sent a patch, unapply all the patches I've given you and apply the new 
 ones
 I've just sent (there are 3) and see how that works for you.  If you don't get
 any BUG()'s but it's still hung then I'll need sysrq+w to see where you are
 hung, we probably screw up unlocking in these codepaths somewhere.  Thanks,

 Josef
--
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: Out of memory condition

[Jérôme Poulin]

I was able to reproduce the problem with the patch, now it fails in
extens_io.c instead of the compression module.

[  243.098892] Out of memory: Kill process 4227 (chrome) score 325 or
sacrifice child
[  243.098895] Killed process 4227 (chrome) total-vm:969800kB,
anon-rss:96824kB, file-rss:1800kB
[  243.146311] chrome: page allocation failure: order:0, mode:0x52
[  243.146315] Pid: 4227, comm: chrome Tainted: G C O
3.5.0-17-generic #27-Ubuntu
[  243.146317] Call Trace:
[  243.146324]  [811281ab] warn_alloc_failed+0xeb/0x140
[  243.146329]  [8112bdf9] __alloc_pages_nodemask+0x659/0x920
[  243.146333]  [81164880] alloc_pages_current+0xb0/0x120
[  243.146360]  [a01d0cd1]
btrfs_submit_compressed_read+0x1c1/0x510 [btrfs]
[  243.146375]  [a018ee31] btrfs_submit_bio_hook+0x141/0x150 [btrfs]
[  243.146387]  [a0191196] ? btrfs_get_extent+0xf6/0x900 [btrfs]
[  243.146402]  [a01ad237] submit_one_bio+0x67/0xa0 [btrfs]
[  243.146415]  [a01b0f29]
submit_extent_page.isra.35+0xa9/0x1f0 [btrfs]
[  243.146427]  [a01b15ae] __extent_read_full_page+0x46e/0x6a0 [btrfs]
[  243.146439]  [a01b0330] ? repair_io_failure+0x1e0/0x1e0 [btrfs]
[  243.146452]  [a01910a0] ? btrfs_real_readdir+0x620/0x620 [btrfs]
[  243.146466]  [a01b2694] extent_readpages+0xc4/0x100 [btrfs]
[  243.146478]  [a01910a0] ? btrfs_real_readdir+0x620/0x620 [btrfs]
[  243.146490]  [a018f2ef] btrfs_readpages+0x1f/0x30 [btrfs]
[  243.146493]  [8112e1c9] __do_page_cache_readahead+0x1b9/0x260
[  243.146496]  [8112e5d1] ra_submit+0x21/0x30
[  243.146499]  [81125423] filemap_fault+0x3f3/0x450
[  243.146503]  [8117bf9f] ? mem_cgroup_update_page_stat+0x1f/0x60
[  243.146506]  [8114693f] __do_fault+0x6f/0x530
[  243.146510]  [81149d94] handle_pte_fault+0x94/0x430
[  243.146514]  [810ab0ab] ? wake_futex+0x3b/0x60
[  243.146517]  [810ab1db] ? futex_wake+0x10b/0x130
[  243.146521]  [8114ae89] handle_mm_fault+0x259/0x320
[  243.146525]  [816856eb] do_page_fault+0x16b/0x4e0
[  243.146529]  [8108a77f] ? __dequeue_entity+0x2f/0x50
[  243.146533]  [810125be] ? __switch_to+0x16e/0x420
[  243.146536]  [810ade1d] ? sys_futex+0x8d/0x190
[  243.146539]  [81682225] page_fault+0x25/0x30
[  243.146541] Mem-Info:
[  243.146542] Node 0 DMA per-cpu:
[  243.146545] CPU0: hi:0, btch:   1 usd:   0
[  243.146547] CPU1: hi:0, btch:   1 usd:   0
[  243.146548] CPU2: hi:0, btch:   1 usd:   0
[  243.146550] CPU3: hi:0, btch:   1 usd:   0
[  243.146551] Node 0 DMA32 per-cpu:
[  243.146553] CPU0: hi:  186, btch:  31 usd:   0
[  243.146555] CPU1: hi:  186, btch:  31 usd:   0
[  243.146557] CPU2: hi:  186, btch:  31 usd:   0
[  243.146558] CPU3: hi:  186, btch:  31 usd:   0
[  243.146559] Node 0 Normal per-cpu:
[  243.146562] CPU0: hi:  186, btch:  31 usd:   0
[  243.146563] CPU1: hi:  186, btch:  31 usd:   0
[  243.146565] CPU2: hi:  186, btch:  31 usd:   0
[  243.146566] CPU3: hi:  186, btch:  31 usd:   0
[  243.146571] active_anon:364240 inactive_anon:8 isolated_anon:0
[  243.146571]  active_file:2106 inactive_file:3378 isolated_file:64
[  243.146571]  unevictable:7829 dirty:333 writeback:0 unstable:0
[  243.146571]  free:21739 slab_reclaimable:7937 slab_unreclaimable:13177
[  243.146571]  mapped:453114 shmem:85612 pagetables:13858 bounce:0
[  243.146574] Node 0 DMA free:15872kB min:260kB low:324kB high:388kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15648kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:32kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? yes
[  243.146579] lowmem_reserve[]: 0 2903 3903 3903
[  243.146583] Node 0 DMA32 free:53844kB min:50068kB low:62584kB
high:75100kB active_anon:1212420kB inactive_anon:119980kB
active_file:5836kB inactive_file:9252kB unevictable:32kB
isolated(anon):0kB isolated(file):256kB present:2972960kB mlocked:32kB
dirty:816kB writeback:0kB mapped:1464712kB shmem:143260kB
slab_reclaimable:9892kB slab_unreclaimable:24052kB kernel_stack:2600kB
pagetables:33620kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:33837 all_unreclaimable? yes
[  243.146589] lowmem_reserve[]: 0 0 1000 1000
[  243.146592] Node 0 Normal free:17240kB min:17248kB low:21560kB
high:25872kB active_anon:244540kB inactive_anon:191132kB
active_file:2588kB inactive_file:4260kB unevictable:31284kB
isolated(anon):0kB isolated(file):0kB present:1024128kB
mlocked:31284kB dirty:516kB writeback:0kB mapped:347744kB
shmem:199188kB slab_reclaimable:21856kB slab_unreclaimable:28624kB
kernel_stack:3360kB pagetables:21812kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:20615 all_unreclaimable? yes

Re: Out of memory condition

[Jérôme Poulin]

:2056kB unevictable:31352kB
isolated(anon):0kB isolated(file):768kB present:1024128kB
mlocked:31352kB dirty:2244kB writeback:0kB mapped:499940kB
shmem:97124kB slab_reclaimable:21028kB slab_unreclaimable:27864kB
kernel_stack:3016kB pagetables:19860kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:83114 all_unreclaimable? no
[ 1027.511173] lowmem_reserve[]: 0 0 0 0
[ 1027.511177] Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 1*64kB 1*128kB
1*256kB 1*512kB 0*1024kB 1*2048kB 3*4096kB = 15332kB
[ 1027.511187] Node 0 DMA32: 4202*4kB 3381*8kB 411*16kB 2*32kB 1*64kB
0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 54400kB
[ 1027.511198] Node 0 Normal: 3232*4kB 89*8kB 3*16kB 4*32kB 4*64kB
1*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 17272kB
[ 1027.511208] 98814 total pagecache pages
[ 1027.511210] 0 pages in swap cache
[ 1027.511212] Swap cache stats: add 0, delete 0, find 0/0
[ 1027.511213] Free swap  = 0kB
[ 1027.511215] Total swap = 0kB
[ 1027.524135] 1046512 pages RAM
[ 1027.524139] 457115 pages reserved
[ 1027.524140] 154033 pages shared
[ 1027.524141] 523655 pages non-shared
[ 1027.524144] [ cut here ]
[ 1027.524175] WARNING: at
/usr/src/linux-source-3.5.0/linux-source-3.5.0-btrfs-oom/fs/btrfs/extent_io.c:4165
alloc_extent_buffer+0x321/0x440 [btrfs]()
[ 1027.524176] Hardware name: UX31E
[ 1027.524178] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O)
vboxnetflt(O) vboxdrv(O) joydev snd_hda_codec_hdmi
snd_hda_codec_realtek rfcomm parport_pc ppdev bnep lp parport
binfmt_misc uvcvideo videobuf2_core videodev videobuf2_vmalloc
videobuf2_memops coretemp kvm_intel kvm rts5139(C) asus_nb_wmi
asus_wmi sparse_keymap snd_hda_intel snd_hda_codec snd_hwdep ath3k
btusb bluetooth snd_pcm snd_seq_midi microcode snd_rawmidi psmouse
serio_raw lpc_ich snd_seq_midi_event mac_hid arc4 snd_seq snd_timer
snd_seq_device ath9k mac80211 snd ath9k_common ath9k_hw ath soundcore
cfg80211 snd_page_alloc mei btrfs(O) zlib_deflate libcrc32c dm_crypt
hid_generic usbhid hid ghash_clmulni_intel aesni_intel cryptd
aes_x86_64 i915 wmi drm_kms_helper drm i2c_algo_bit video
[ 1027.524233] Pid: 7674, comm: Chrome_ChildIOT Tainted: G  D  C O
3.5.0-17-generic #27-Ubuntu
[ 1027.524235] Call Trace:
[ 1027.524242]  [81051c4f] warn_slowpath_common+0x7f/0xc0
[ 1027.524245]  [81051caa] warn_slowpath_null+0x1a/0x20
[ 1027.524260]  [a01b4d51] alloc_extent_buffer+0x321/0x440 [btrfs]
[ 1027.524273]  [a01891a5]
btrfs_find_create_tree_block+0x25/0x30 [btrfs]
[ 1027.524285]  [a018929f] readahead_tree_block+0x1f/0x60 [btrfs]
[ 1027.524295]  [a016ea0d]
read_block_for_search.isra.43+0x32d/0x3f0 [btrfs]
[ 1027.524309]  [a01c6f90] ? btrfs_tree_read_unlock+0x50/0xa0 [btrfs]
[ 1027.524319]  [a0170cd0] btrfs_search_slot+0x360/0x8f0 [btrfs]
[ 1027.524332]  [a0184198] btrfs_lookup_file_extent+0x38/0x40 [btrfs]
[ 1027.524345]  [a0193251] btrfs_get_extent+0x1b1/0x900 [btrfs]
[ 1027.524361]  [a01ae690] ?
btrfs_lookup_ordered_extent+0x90/0xd0 [btrfs]
[ 1027.524375]  [a01b3418] __extent_read_full_page+0x2d8/0x6b0 [btrfs]
[ 1027.524379]  [8117b92b] ? mem_cgroup_charge_common+0x6b/0xa0
[ 1027.524393]  [a01930a0] ? btrfs_real_readdir+0x620/0x620 [btrfs]
[ 1027.524407]  [a01b46a4] extent_readpages+0xc4/0x100 [btrfs]
[ 1027.524420]  [a01930a0] ? btrfs_real_readdir+0x620/0x620 [btrfs]
[ 1027.524432]  [a01912ef] btrfs_readpages+0x1f/0x30 [btrfs]
[ 1027.524436]  [8112e1c9] __do_page_cache_readahead+0x1b9/0x260
[ 1027.524439]  [8112e5d1] ra_submit+0x21/0x30
[ 1027.524443]  [81125423] filemap_fault+0x3f3/0x450
[ 1027.524447]  [8117bf9f] ? mem_cgroup_update_page_stat+0x1f/0x60
[ 1027.524451]  [8114693f] __do_fault+0x6f/0x530
[ 1027.524456]  [81149d94] handle_pte_fault+0x94/0x430
[ 1027.524459]  [8114ae89] handle_mm_fault+0x259/0x320
[ 1027.524464]  [816856eb] do_page_fault+0x16b/0x4e0
[ 1027.524468]  [812b2c12] ? security_file_permission+0x92/0xb0
[ 1027.524471]  [81682225] page_fault+0x25/0x30
[ 1027.524474] ---[ end trace 6f136eb0e3515ae1 ]---
[ 1099.700074] vboxnetflt: dropped 0 out of 709 packets


On Fri, Oct 5, 2012 at 1:43 PM, Josef Bacik jba...@fusionio.com wrote:
 On Fri, Oct 05, 2012 at 11:20:37AM -0600, Jérôme Poulin wrote:
 I was able to reproduce the problem with the patch, now it fails in
 extens_io.c instead of the compression module.


 Yeah so I fixed the compression side, and now it's erroring out further down.
 So leave the patch I gave you applied as it is correct, and apply this patch 
 and
 see if it helps.  Thanks,

 Josef

 diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
 index b82d244..8c37cb6 100644
 --- a/fs/btrfs/extent_io.c
 +++ b/fs/btrfs/extent_io.c
 @@ -2751,12 +2751,15 @@ static int __extent_read_full_page(struct 
 extent_io_tree *tree

Re: cross-subvolume cp --reflink

[Jérôme Poulin]

On Thu, Aug 16, 2012 at 5:41 PM, james northrup
northrup.ja...@gmail.com wrote:

 dunno if this thread is dead, but im inclined to patch in cp --reflink to 
 fdupes prog.
  It  currently does provide a poor-man's dedupe via md5sum and hardlink, or 
 delete.

 all the better if the distro-kernels can backport cross-snapshot reflinks 
 sooner than later.


I was also wondering if it is possible for a program like fdupes to
use BTRFS checksum to make searching for duplicates much faster as you
wouldn't need to calculate checksum if BTRFS own checksum was
mismatched between 2 groups of checksum blocks?
--
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 panic in 3.5.0

[Jérôme Poulin]

On Tue, Aug 7, 2012 at 1:40 PM, Marc MERLIN m...@merlins.org wrote:

 System rebooted ok.

I just want to be sure that you are aware that your hard drive is
currently killing itself. Those READ FPDMA QUEUED mean that your hard
disk is relocatting bad sectors and has problem reading those.
--
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: [PATCH 3/3] Add btrfs filesystem info man page.

[Jérôme Poulin]

What kind of info does it give? This is really unhelpful in a man
page, it just tells the obvious.

On Fri, Jun 8, 2012 at 3:12 PM, Goffredo Baroncelli kreij...@inwind.it wrote:

 Update the man page to document the btrfs filesystem info path
 command.
 ---
  man/btrfs.8.in |    8 
  1 file changed, 8 insertions(+)

 diff --git a/man/btrfs.8.in b/man/btrfs.8.in
 index be478e0..6d96bf7 100644
 --- a/man/btrfs.8.in
 +++ b/man/btrfs.8.in
 @@ -25,6 +25,8 @@ btrfs \- control a btrfs filesystem
  .PP
  \fBbtrfs\fP \fBfilesystem defrag\fP\fI [options] file|dir 
 [file|dir...]\fP
  .PP
 +\fBbtrfs\fP \fBfilesystem info\fP\fI path\fP
 +.PP
  \fBbtrfs\fP \fBsubvolume find-new\fP\fI subvolume last_gen\fP
  .PP
  \fBbtrfs\fP \fBfilesystem balance\fP\fI path \fP
 @@ -154,6 +156,12 @@ The start position and the number of bytes to 
 deframention can be specified by \
  NOTE: defragmenting with kernels up to 2.6.37 will unlink COW-ed copies of 
 data, don't
  use it if you use snapshots, have de-duplicated your data or made copies with
  \fBcp --reflink\fP.
 +.TP
 +
 +\fBfilesystem info\fP \fIpath\fR
 +Get filesystem info.
 +.TP
 +
  \fBsubvolume find-new\fR\fI subvolume last_gen\fR
  List the recently modified files in a subvolume, after \fIlast_gen\fR ID.
  .TP
 --
 1.7.10

 --
 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: New btrfs-progs integration branch

[Jérôme Poulin]

On Tue, Jun 5, 2012 at 3:09 PM, Hugo Mills h...@carfax.org.uk wrote:

   I've just pushed out a new integration branch to my git repo. This
 is purely bugfix patches -- there are no new features in this issue of
 the integration branch. I've got a stack of about a dozen more patches
 with new features in them still to go.


I was wondering if in the new patches you had the ReiserFS converter in queue?
http://www.spinics.net/lists/linux-btrfs/msg04985.html

It seems out for a while, I did try it out without any issue on my
main partition 2 years ago. This is not my patch but would you need
more testing before getting it integrated?

-- Repost, forgot to disable 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: filesystem full when it's not? out of inodes? huh?

[Jérôme Poulin]

On Sun, Feb 26, 2012 at 1:14 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:

 # btrfs fi resize 5G /usr; df -h /usr
 Resize '/usr' of '5G'


What would be interesting is getting an eye on btrfs fi df of your
filesystem to see what part is getting full, or maybe just do a
balance.

I have been running 3.0.0 for quite a while without any problem,
metadata grew a bit too much (1.5 TB for 2 TB of data) and balance
fixed it back to 50 GB of metadata then 20 GB after deleting some
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: [PATCH 00/21] Btrfs: restriper

[Jérôme Poulin]

On Tue, Feb 14, 2012 at 9:18 AM, Ilya Dryomov idryo...@gmail.com wrote:

 Just to be sure, could you please paste the output of
 `btrfs-debug-tree -d your device' somewhere ?

Here it is: http://paste.pocoo.org/show/550900/

I also had btrsck errors before and still have them with 3 new after
balance (I guess it duplicated them :)
root 424 inode 291690 errors 400
root 424 inode 18446744073709551604 errors 2000
root 424 inode 18446744073709551605 errors 1

Full btrfsck: http://paste.pocoo.org/show/550902/
--
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: [PATCH 00/21] Btrfs: restriper

[Jérôme Poulin]

On Fri, Jan 6, 2012 at 9:30 AM, Ilya Dryomov idryo...@gmail.com wrote:
 This is a respin of restriper patch series which adds an initial
 implementation of restriper (it's a clever name for relocation framework
 that allows to do selective profile changing and selective balancing
 with some goodies like pausing/resuming and reporting progress to the
 user).  See userspace cover patch for usage examples.

I just tried merging this on my kernel 3.2.1 and it seems to work
nicely. I compiled your btrfs-progs, made an LVM snapshot and launched
a balance on my 300 GB filesystem converted from ext4. It worked for
converting my metadata from single to dup, however, it didn't succeed
converting my system from single to dup.

Here is the command I used:
root /usr/src/kernel/btrfs-progs # ./btrfs balance start -f -v
-sconvert=dup -mconvert=dup /mnt/btrfs/
Dumping filters: flags 0xe, state 0x0, force is on
  METADATA (flags 0x100): converting, target=32, soft is off
  SYSTEM (flags 0x100): converting, target=32, soft is off
Done, had to relocate 28 out of 220 chunks

Then tried:
root /usr/src/kernel/btrfs-progs # ./btrfs balance start -f -v
-sconvert=dup /mnt/btrfs/
Dumping filters: flags 0xa, state 0x0, force is on
  SYSTEM (flags 0x100): converting, target=32, soft is off
Done, had to relocate 0 out of 239 chunks

Before:
root /usr/src/kernel/btrfs-progs # ./btrfs fi df /mnt/btrfs/
Data: total=217.33GB, used=211.68GB
System: total=32.00MB, used=28.00KB
Metadata: total=19.39GB, used=14.18GB

And here is the result after balance:
root /usr/src/kernel/btrfs-progs # ./btrfs fi df /mnt/btrfs/
Data: total=226.33GB, used=225.56GB
System: total=32.00MB, used=36.00KB
Metadata, DUP: total=4.75GB, used=297.77MB

I also used the status command which was working correctly.
--
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: Cross-subvolume reflink copy (BTRFS_IOC_CLONE over subvolume boundaries)

[Jérôme Poulin]

On Mon, Feb 13, 2012 at 6:52 PM, Hubert Kario h...@qbs.com.pl wrote:
 It's been nearly a year since the patches needed to implement a reflinked copy
 between subvolumes have been posted
 (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865 ) and I still
 get Invalid cross-device link error with Linux 3.2.4 while I try to do a cp
 --reflink between subvolumes.

I am still keeping this patch up-to-date in my personal kernel repo.

Here is the diff from current for-linus

BTRFS-Allow-cross-subvolume-BTRFS_IOC_CLONE.patch

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 0b06a5c..05dc644 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2203,6 +2203,7 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
 {
struct inode *inode = fdentry(file)-d_inode;
struct btrfs_root *root = BTRFS_I(inode)-root;
+   struct btrfs_root *srcroot;
struct file *src_file;
struct inode *src;
struct btrfs_trans_handle *trans;
@@ -2245,6 +2246,7 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
}

src = src_file-f_dentry-d_inode;
+   srcroot = BTRFS_I(src)-root;

ret = -EINVAL;
if (src == inode)
@@ -2264,11 +2266,11 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
goto out_fput;

ret = -EXDEV;
-   if (src-i_sb != inode-i_sb || BTRFS_I(src)-root != root)
+   if (src-i_sb != inode-i_sb)
goto out_fput;

ret = -ENOMEM;
-   buf = vmalloc(btrfs_level_size(root, 0));
+   buf = vmalloc(btrfs_level_size(srcroot, 0));
if (!buf)
goto out_fput;

@@ -2338,13 +2340,13 @@ static noinline long btrfs_ioctl_clone(struct
file *file, unsigned long srcfd,
 * note the key will change type as we walk through the
 * tree.
 */
-   ret = btrfs_search_slot(NULL, root, key, path, 0, 0);
+   ret = btrfs_search_slot(NULL, srcroot, key, path, 0, 0);
if (ret  0)
goto out;

nritems = btrfs_header_nritems(path-nodes[0]);
if (path-slots[0] = nritems) {
-   ret = btrfs_next_leaf(root, path);
+   ret = btrfs_next_leaf(srcroot, path);
if (ret  0)
goto out;
if (ret  0)
--
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: Btrfsck gives me errors

[Jérôme Poulin]

On Fri, Jan 20, 2012 at 2:19 AM, Fajar A. Nugraha l...@fajar.net wrote:
 Then again, most fsck feature has been implemented in kernel space so
 a mount will automatically fix some types of problems (somewhat
 similar to what zfs does, which has no fsck whatsoever). So just watch
 syslog for any unusual error messages.

However it has a way to be fully backed up without losing space which
have been saved using snapshot and reflinks. Right now, this is not
production critical data, so I've got backups only of files I think
are critical to me, not reflinks and 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: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE

[Jérôme Poulin]

Is there any reason why this can't be applied in for-linus? Does it
need more testing? Still no corruption here after copying the whole
root FS in subvolume after btrfs-convert, this FS is used everyday
with big image files, clients backups of Windows directories (small
files) and 3 snapshots a day, using cp --reflink for whole image copy
to test recovery and more.

BTRFS is the only module I need to recompile on this machine after
each upgrading the kernel to apply this patch.

On Mon, Jan 9, 2012 at 8:31 AM, Jérôme Poulin jeromepou...@gmail.com wrote:
 On Mon, Jan 9, 2012 at 1:58 AM, Marios Titas redneb8...@gmail.com wrote:
 The simple case of 'cp --reflink' works fine [...]

 It doesn't work here:

 cp: failed to clone `/tmp/test': Invalid cross-device link

 That's with 3.1 + for-linus.

 This is the problem, it doesn't work because you have to apply the
 patch at http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865
 which is not mainlined yet. This patch dates back from March 31st, I
 have been using it since it was released.
--
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: Btrfsck gives me errors

[Jérôme Poulin]

On Wed, Jan 18, 2012 at 11:59 PM, Fajar A. Nugraha l...@fajar.net wrote:
 Recent kernels (e.g. 3.1 or 3.2) is smart enough to automatically fix
 certain types of errors. Watch syslog when you mount the fs, access
 some files, unmount, and mount it again. If second mount does not show
 any error message then I'm pretty sure you're safe.

I just upgraded from 3.0 to 3.2.1 and mounted the filesystem, tried
find  /dev/null and only got messages about old space inode. I then
used btrfsck again for the same exact result, I'll ignore them for
now, let's see what the shiny new btrfsck will do about them!
--
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

Btrfsck gives me errors

[Jérôme Poulin]

I did a preemptive fsck after a RAID crash and got many errors, is
there something I should do if everything I use works?

root 412 inode 427 errors 400
root 412 inode 430 errors 400
root 412 inode 434 errors 400
root 412 inode 436 errors 400
root 412 inode 440 errors 400
root 412 inode 446 errors 400
root 412 inode 448 errors 400
root 412 inode 452 errors 400
root 412 inode 458 errors 400
root 412 inode 464 errors 400
root 412 inode 466 errors 400
root 412 inode 476 errors 400
root 412 inode 479 errors 400
root 412 inode 495 errors 400
root 412 inode 498 errors 400
root 412 inode 515 errors 400
root 412 inode 518 errors 400
root 412 inode 522 errors 400
root 412 inode 524 errors 400
root 412 inode 534 errors 400
root 412 inode 537 errors 400
root 412 inode 541 errors 400
root 412 inode 543 errors 400
root 412 inode 560 errors 400
root 412 inode 563 errors 400
root 412 inode 580 errors 400
root 412 inode 583 errors 400
root 412 inode 600 errors 400
root 412 inode 603 errors 400
root 412 inode 607 errors 400
root 412 inode 620 errors 400
root 412 inode 623 errors 400
root 412 inode 627 errors 400
root 412 inode 640 errors 400
root 412 inode 643 errors 400
root 412 inode 647 errors 400
root 412 inode 649 errors 400
root 412 inode 660 errors 400
root 412 inode 663 errors 400
root 412 inode 667 errors 400
root 412 inode 669 errors 400
root 412 inode 680 errors 400
root 412 inode 683 errors 400
root 412 inode 700 errors 400
root 412 inode 703 errors 400
root 412 inode 719 errors 400
root 412 inode 722 errors 400
root 412 inode 726 errors 400
root 412 inode 739 errors 400
root 412 inode 742 errors 400
root 412 inode 746 errors 400
root 412 inode 748 errors 400
root 412 inode 752 errors 400
root 412 inode 754 errors 400
root 412 inode 771 errors 400
root 412 inode 774 errors 400
root 412 inode 780 errors 400
root 412 inode 782 errors 400
root 412 inode 786 errors 400
root 412 inode 788 errors 400
root 412 inode 792 errors 400
root 412 inode 794 errors 400
root 412 inode 798 errors 400
root 412 inode 800 errors 400
root 412 inode 804 errors 400
root 412 inode 806 errors 400
root 412 inode 810 errors 400
root 412 inode 812 errors 400
root 412 inode 816 errors 400
root 412 inode 818 errors 400
root 412 inode 822 errors 400
root 412 inode 824 errors 400
root 412 inode 828 errors 400
root 412 inode 830 errors 400
root 412 inode 834 errors 400
root 412 inode 836 errors 400
root 412 inode 840 errors 400
root 412 inode 846 errors 400
root 412 inode 852 errors 400
root 412 inode 854 errors 400
root 412 inode 858 errors 400
root 412 inode 864 errors 400
root 412 inode 866 errors 400
root 412 inode 870 errors 400
root 412 inode 872 errors 400
root 412 inode 876 errors 400
root 412 inode 878 errors 400
root 412 inode 882 errors 400
root 412 inode 885 errors 400
root 412 inode 888 errors 400
root 412 inode 891 errors 400
root 412 inode 894 errors 400
root 412 inode 897 errors 400
root 412 inode 900 errors 400
root 412 inode 903 errors 400
root 412 inode 906 errors 400
root 412 inode 909 errors 400
root 412 inode 912 errors 400
root 412 inode 938 errors 400
root 412 inode 940 errors 400
root 412 inode 944 errors 400
root 412 inode 946 errors 400
root 412 inode 950 errors 400
root 412 inode 963 errors 400
root 412 inode 966 errors 400
root 412 inode 983 errors 400
root 412 inode 986 errors 400
root 412 inode 990 errors 400
root 412 inode 1002 errors 400
root 412 inode 1005 errors 400
root 412 inode 1022 errors 400
root 412 inode 1025 errors 400
root 412 inode 1029 errors 400
root 412 inode 1031 errors 400
root 424 inode 291690 errors 400
found 222893703168 bytes used err is 1
total csum bytes: 217378224
total tree bytes: 288571392
total fs tree bytes: 23961600
btree space waste bytes: 29683827
file data blocks allocated: 11876872372224
 referenced 226945392640
Btrfs Btrfs v0.19
--
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: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE

[Jérôme Poulin]

On Mon, Jan 9, 2012 at 1:58 AM, Marios Titas redneb8...@gmail.com wrote:
 The simple case of 'cp --reflink' works fine [...]

 It doesn't work here:

 cp: failed to clone `/tmp/test': Invalid cross-device link

 That's with 3.1 + for-linus.

This is the problem, it doesn't work because you have to apply the
patch at http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865
which is not mainlined yet. This patch dates back from March 31st, I
have been using it since it was released.
--
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: COW a file from snapshot

[Jérôme Poulin]

Did you get any success with the patch?
Reading the conversation, people seemed to agree that this feature
should be included, anyway, snapshot already share data, why not be
able to copy them?

Other link with title for mailing list reference.
[PATCH 2/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865

On Tue, Dec 20, 2011 at 12:53 PM, Jérôme Poulin jeromepou...@gmail.com wrote:

 You would need to apply this patch to your kernel:
 http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg09096.html

 Is there any chance this patch gets in linux-next ?
 I use this feature all the time and it never broke on me.
--
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: COW a file from snapshot

[Jérôme Poulin]

You would need to apply this patch to your kernel:
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg09096.html

Is there any chance this patch gets in linux-next ?
I use this feature all the time and it never broke on me.

On Tue, Dec 20, 2011 at 10:07 AM, Dave d...@thekilempire.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 So I've got a daily snapshot of my /home subvolume.  Due to a fat finger, I've
 damaged a rather large file so I'd like to pull if from one of these snapshot
 backups.  I don't want to simply copy the file since it's many gigs and cp
 - --reflink=always doesn't work (produces the error Invalid cross-device 
 link).
 Is there a way to recover that file and benefit from COW?
 - --
 - -=[dave]=-

 Entropy isn't what it used to be.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)

 iF4EAREIAAYFAk7wpKUACgkQXM0u5ajNnCgMUQD/Uf0/HygZ9D8StT9Oc6E3+wM/
 MBokh6h1iPN2OslJTxgA/RUzFMM2n0+3ORHwvOraJMBJl1P4JfabT31iuemn/BL2
 =2cds
 -END PGP SIGNATURE-
 --
 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: Snapshot of root makes an undeletable folder

[Jérôme Poulin]

On Sun, Sep 4, 2011 at 5:05 PM, Ilya Dryomov idryo...@gmail.com wrote:
 On Sun, Sep 04, 2011 at 11:29:43AM -0400, Jérôme Poulin wrote:
 Then I though about my folder organization again and renamed music to
 downloads, this is still OK and then create music in downloads, I was
 told music already exists, however I can't neither see it, list it,
 cd to it or remove it.

 This is because music directory actually exists.  When you executed

 btrfs sub snap . music

 btrfs created music directory item in your default subvolume and *then*
 took a snapshot of the default subvolume with that music directory item
 already in it.  Btrfs readdir skips references from the snapshot to
 itself, so you can't see it.  Even though you renamed your snapshot to
 downloads, snapshot's contents still don't allow you to create a
 music directory in it.


I understand that btrfs creates a snapshot containing the snapshot
directory however in my tests on a clean FS, as soon as I create a
second snapshot I am able to rmdir it.

 The correct way to do what you want is to create a subvolume music,
 and move folders from default to music.  Then you can snapshot your
 newly created music subvolume in a clean way, rename it, etc.


This is where cp --reflink=always is useful as move copies the files
across subvolumes.

 I then made a snapshot of downloads to music and now music is listed as:
 ls: cannot access /mnt/btrfs/downloads/music: No such file or directory
 d? ? ?      ?         ?            ? music

 What command and in what directory did you run to make a snapshot of
 downloads to music ?  I can't reproduce this off-hand.


I wasn't able to reproduce this unreadable directory using a clean FS
or similar operations, this was just 'ls' trying to list the downloads
directory.

 btrfsck gives me:
...

 There is also a OOPS associated to it:
...


 So as a workaround I applied to my kernel 2 patches:
 * Btrfs-reverse-enough-space-for-file-clone.patch
 (I hope this patch is in 3.1, as it could cause DoS else.)
 * 2-2-btrfs-allow-cross-subvolume-BTRFS_IOC_CLONE.patch


Any idea why those patch aren't part of the main tree yet?

 I snapshotted the btrfs volume using LVM to test, made a new
 subvolume, cp -a --reflink=always the content of the downloads
 subvolume except music, then deleted the other subvolume, and now
 everything works, btrfsck is happy and no more problems.


And will the filesystem be stable if I use this method? Or should I
re-make a new btrfs ?

 I will keep working with the old subvolume until I get an answer in
 case you need more informations.

Should I keep it?

 I can also tell that this is half-reproducible using a new btrfs
 filesystem and snapshotting the root, except that after the second
 snapshot the folder won't appear as unlistable, however it is not
 removable unless you delete the original subvolume.

 I'm not sure what do you mean by it's not removable part, but the part
 where after a second snapshot you can see the folder is expected
 behaviour due to the fact that Btrfs allows subvolumes (and snapshots)
 anywhere in the tree, but with only one access point (the dentry added
 on creation).  This is done to avoid various problems related to hard
 links, and the rest of those points appear as empty directories with a
 special inode number.


This is to be expected after what you explained.
--
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

Snapshot of root makes an undeletable folder

[Jérôme Poulin]

I recently converted a long-used ext4 filesystem after e2fsck to btrfs
using btrfs-convert, everything went fine and all my files are there.
I then decided to make the filesystem more managable so I made a
snapshot of the root and removed the rest of the root like:

Original listing:
ext2_saved folder1 folder2 folder3 folder4 lost+found

btrfs sub snap . music
rm -rf folder1 folder2 folder3 folder4 lost+found music/lost+found

So now I end up with only a music folder on root which I was able to
mount using subvol= to another folder and use the btrfs FS for other
subvolumes.

The next day I decided to remove the ext2_image snapshot and grow the
filesystem to accomodate for other files, this was still OK.

Then I though about my folder organization again and renamed music to
downloads, this is still OK and then create music in downloads, I was
told music already exists, however I can't neither see it, list it,
cd to it or remove it.

I then made a snapshot of downloads to music and now music is listed as:
ls: cannot access /mnt/btrfs/downloads/music: No such file or directory
d? ? ?  ? ?? music

btrfsck gives me:
root /mnt # btrfsck /dev/vgP4RAID5/btrfs
root 289 root dir 256 error
found 52167258112 bytes used err is 1
total csum bytes: 50868244
total tree bytes: 76210176
total fs tree bytes: 6860800
btree space waste bytes: 15322691
file data blocks allocated: 52091047936
 referenced 52091047936
Btrfs v0.19-35-g1b444cd-dirty


There is also a OOPS associated to it:
[82291.652513] new size for /dev/mapper/vgP4RAID5-btrfs is 75161927680
[83636.560865] btrfs failed to delete reference to music, inode 263 parent 256
[83679.232134] [ cut here ]
[83679.232142] WARNING: at fs/dcache.c:1350 d_set_d_op+0x8e/0xc0()
[83679.232144] Hardware name: P55-USB3
[83679.232145] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
nvidia(P) squashfs xfs exportfs reiserfs ext3 jbd
snd_hda_codec_realtek usbhid snd_hda_intel snd_hda_codec hid usblp
snd_hwdep snd_pcm sg i2c_i801 intel_agp snd_timer snd evdev ppdev
parport_pc soundcore snd_page_alloc i2c_core r8169 intel_gtt parport
mii processor pcspkr iTCO_wdt iTCO_vendor_support button ipv6 sr_mod
sd_mod cdrom pata_acpi pata_jmicron ahci libahci libata uhci_hcd
xhci_hcd btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16
fuse usb_storage scsi_mod ehci_hcd usbcore raid456 async_raid6_recov
async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod
dm_snapshot dm_mod loop
[83679.232186] Pid: 14614, comm: ls Tainted: P3.0.4-Ti #2
[83679.232187] Call Trace:
[83679.232193]  [8105c7ef] warn_slowpath_common+0x7f/0xc0
[83679.232195]  [8105c84a] warn_slowpath_null+0x1a/0x20
[83679.232196]  [8116bdfe] d_set_d_op+0x8e/0xc0
[83679.232199]  [8117c50f] simple_lookup+0x3f/0x60
[83679.232201]  [811626f5] d_alloc_and_lookup+0x45/0x90
[83679.232204]  [8116f765] ? d_lookup+0x35/0x60
[83679.232206]  [81163f5e] do_lookup+0x29e/0x310
[83679.232208]  [81164bdc] path_lookupat+0x11c/0x700
[83679.232210]  [811651f1] do_path_lookup+0x31/0xc0
[83679.232211]  [81166db9] user_path_at+0x59/0xa0
[83679.232214]  [812b871b] ? tty_ioctl+0x5cb/0xbc0
[83679.232217]  [810398f0] ? do_page_fault+0x1c0/0x4d0
[83679.232220]  [8115c284] vfs_fstatat+0x44/0x70
[83679.232224]  [81072f0d] ? do_sigaction+0x12d/0x1f0
[83679.232226]  [8115c2eb] vfs_stat+0x1b/0x20
[83679.232227]  [8115c42a] sys_newstat+0x1a/0x40
[83679.232229]  [810732dd] ? sys_rt_sigaction+0x8d/0xc0
[83679.232233]  [813f4485] ? page_fault+0x25/0x30
[83679.232267]  [813f4a42] system_call_fastpath+0x16/0x1b
[83679.232269] ---[ end trace 6bdc8b9bb849be1c ]---
[83679.232270] [ cut here ]
[83679.232272] WARNING: at fs/dcache.c:1354 d_set_d_op+0xb1/0xc0()
[83679.232273] Hardware name: P55-USB3
[83679.232274] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
nvidia(P) squashfs xfs exportfs reiserfs ext3 jbd
snd_hda_codec_realtek usbhid snd_hda_intel snd_hda_codec hid usblp
snd_hwdep snd_pcm sg i2c_i801 intel_agp snd_timer snd evdev ppdev
parport_pc soundcore snd_page_alloc i2c_core r8169 intel_gtt parport
mii processor pcspkr iTCO_wdt iTCO_vendor_support button ipv6 sr_mod
sd_mod cdrom pata_acpi pata_jmicron ahci libahci libata uhci_hcd
xhci_hcd btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16
fuse usb_storage scsi_mod ehci_hcd usbcore raid456 async_raid6_recov
async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 md_mod
dm_snapshot dm_mod loop
[83679.232309] Pid: 14614, comm: ls Tainted: PW   3.0.4-Ti #2
[83679.232310] Call Trace:
[83679.232313]  [8105c7ef] warn_slowpath_common+0x7f/0xc0
[83679.232316]  [8105c84a] warn_slowpath_null+0x1a/0x20
[83679.232318]  [8116be21] d_set_d_op+0xb1/0xc0
[83679.232321]  [8117c50f] simple_lookup+0x3f/0x60

Re: snapshot ctime // Re: [RFC] btrfs auto snapshot

[Jérôme Poulin]

On Wed, Aug 17, 2011 at 11:13 AM, Roman Mamedov r...@romanrm.ru wrote:
 So until someone cares about snapshot ctime enough to fix this, btrfs will 
 not be a convenient FS to work with timed snapshotting/cleanup.

Isn't the ctime the creation date of the original folder?
--
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: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE

[Jérôme Poulin]

I am very happy to see this patch. It was one of the first thing I
tried after making a subvolume, cp --reflink, and it failed. I'll have
to try this out.

Jérôme Poulin

On 2011-04-02, at 12:56, Larry D'Anna la...@elder-gods.org wrote:

 * Ken Drummond (bt...@kendrummond.com) [110402 11:51]:
 I don't really understand the details here, but doesn't the creation of
 a snapshot already lead to data extents being shared between
 sub-volumes?  From a simple user perspective this sounds like a very
 useful capability.

 I was surprised and frustrated to find it missing.  I had just copied a large
 quantity of data into btrfs, realized i need to make a subvolume to try out
 snapshotting, and then found out i had to copy all the data *again* to get it
 into a subvolume.  There are tons of scenarios where users will want and 
 expect
 to be able to do this.
 --
 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 system won't start on Ubuntu (relationship problems...)

[Jérôme Poulin]

Re-send as non-HTML
On Sun, Mar 13, 2011 at 7:46 AM, Peter Stuge pe...@stuge.se wrote:

 Pau Iranzo wrote:
  I installed Ubuntu on my girlfriend's laptop using btrfs as a
  filesystem. But a few weeks ago something happened: the system
  wouldn't boot and always show these messages:
  http://dl.dropbox.com/u/120126/btrfs/IMG_20110313_122119.jpg
  http://dl.dropbox.com/u/120126/btrfs/IMG_20110313_122125.jpg
  http://dl.dropbox.com/u/120126/btrfs/IMG_20110313_122143.jpg

 The hard drive is broken.

 This would have happened at the same point in time regardless of
 btrfs or not, and regardless of Linux or not.


Just to confirm, the hard disk is broken, I guess you installed Ubuntu
first because Windows was getting slow, it probably was the hard disk
at this time.


  The problem is that there is now way to mount that partition and all
  the analysis tools don't give any information. I know there is no fsck
  for btrfs, so it is just a shame for me, because my girlfriend is
  really angry at me for this.
 
  Foremost is not able to recover files neither.
 
  Could anyone help me on this? I don't mind if the system does not
  start, but I need to recover some files (pictures basically).

 Take out the disk from the machine. Get a USB-adapter. Prepare for
 running dd_rescue on another Linux system. Hook up broken drive. Run
 dd_rescue to make a copy of the disk that you can work on. Disconnect
 broken drive. Every second it is powered the chance to recover data
 decreases. Only power it up when you must, and when you are well
 prepared to extract complete contents from the disk. Try to analyze
 how the btrfs is broken. Try to fix it. Mount and recover data.

 Meanwhile buy new hard drive and reinstall a system so your friend
 has a working computer.


Never plug a defective drive on USB if it is the source, only the
destination can be plugged USB, else defective sectors get transferred
as good filled with random stuff and it only makes data recovery
worst, also, there is ddrescue and dd_rescue, you try both, just make
sure you save a logfile, I don't remember if dd_rescue has one.


 //Peter

--
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 system won't start on Ubuntu (relationship problems...)

[Jérôme Poulin]

On Sun, Mar 13, 2011 at 12:30 PM, Peter Stuge pe...@stuge.se wrote:

 Jérôme Poulin wrote:
  Never plug a defective drive on USB if it is the source .. else
  defective sectors get transferred as good filled with random stuff

 Interesting! Which USB chipset(s?) have you seen do this?


Those I tried and confirmed not working are
CablesToGo: http://www.cablestogo.com/product.asp?cat_id=941sku=30504
StarTech: http://us.startech.com/product/USB2SATAIDE-USB-20-to-IDE-or-SATA-Adapter-Cable

I don't have them handy but I can confirm you the chipset if you'd like.

As a sidenote USB converters don't have low level access to the disk
so it also makes smartctl and stuff not working at all.
I was not able to find any USB converter which was working correctly
using ddrescue and a defective disk yet.


 //Peter
--
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

Stuck in a big loop

[Jérôme Poulin]

Hi,

I've got a filesystem I use to compile OpenWRT, it is ordered like:
Original firmware, updated once in a while:
sources/original-sources/backfire
sources/original-sources/trunk

Downloads and some other stuff:
dl/
stuff/

Test compiles:
sources/compiles
sources/old-date/old compiles


The filesystem was created with kernel 2.6.35, and I was able to have
about 6 compiles from original-sources and 4 others snapshotted from
already compiled stuff.
Filesystem has always been mounted with -o compress

I upgraded to 2.6.37 recently, decided to mount with -o space_cache to
see if it improves performance a bit,
I updated my sources in original-sources, then made a snapshot of one
of the original tree.
I had open files in a older compile directory and deleted that
subvolume while files were open, it disappeared but files were still
open.
I then decided to make menuconfig in the newly created snapshot, it
hung with 'awk' and 'flush-btrfs' using 100% CPU.
Then I found out about those open files, killed everything using those
old file and the new subvolume, it de-froze after about 5 minutes.
I umounted the btrfs filesystem and remounted it again, all fine, I
was able to compile the new snapshot. Some events about hung tasks
appeared in the dmesg log, I will attach them at the end of the
message.

Today, 2 days later, I made a new snapshot of the original sources and
started make menuconfig right away, now 'perl' and 'flush-btrfs' use
100% CPU again and now 30 minutes later, they are still stuck so I
dumped process using SysRq+T, i guess this could be a bug in 2.6.37 or
space_cache ? 2.6.37 is vanilla and btrfs-progs is
v0.19-16-g075587c-dirty.

Here follow the stack dump of 'perl' and 'flush-btrfs', the 2
processes are mostly in 'R' state and use around 40-60% CPU each and
complete themselve to 100%:

=== Perl ===
[334438.931233] perl  W 8151ea5a  4848 32252  1 0x0004
[334438.931245]  8800612bf9b8 8151eae5 8800df48d680
88011b676740
[334438.931256]    8800612bffd8
00011a80
[334438.931267]  880049365880 880049365c18 880049365c10
8800612be000
[334438.931277] Call Trace:
[334438.931284]  [8102f274] ? enqueue_entity+0x218/0x221
[334438.931291]  [8151ed06] schedule_timeout+0x22/0xbb
[334438.931298]  [8102ff83] pick_next_task+0x25/0x4b
[334438.931305]  [81520059] ? _raw_spin_unlock_irqrestore+0x20/0x2b
[334438.931312]  [81035cab] try_to_wake_up+0x235/0x250
[334438.931321]  [81520083] ? _raw_spin_unlock_irq+0x1f/0x2a
[334438.931327]  [8151e2ca] ? wait_for_common+0x9e/0x10b
[334438.931335]  [8103ed23] ? local_bh_enable_ip+0x9/0xb
[334438.931341]  [8151e3d1] ? wait_for_completion+0x18/0x1a
[334438.931349]  [810e560d] ? writeback_inodes_sb_nr+0x71/0x78
[334438.931356]  [8151ed83] ? schedule_timeout+0x9f/0xbb
[334438.931363]  [810e5a35] ? writeback_inodes_sb_nr_if_idle+0x3c/0x52
[334438.931382]  [a0dd2c94] ? shrink_delalloc+0xac/0x140 [btrfs]
[334438.931401]  [a0dd3437] ?
btrfs_delalloc_reserve_metadata+0x134/0x146 [btrfs]
[334438.931420]  [a0dd6f52] ?
btrfs_delalloc_reserve_space+0x25/0x42 [btrfs]
[334438.931447]  [a0df046e] ? btrfs_file_aio_write+0x55a/0x918 [btrfs]
[334438.931455]  [810dc387] ? touch_atime+0x82/0x13a
[334438.931463]  [8109adc7] ? lru_cache_add_lru+0x3c/0x3e
[334438.931469]  [810b1489] ? page_add_new_anon_rmap+0x75/0x87
[334438.931476]  [810c9d58] ? do_sync_write+0xc6/0x103
[334438.931483]  [811fdf05] ? security_file_permission+0x29/0x2e
[334438.931490]  [810ca2b1] ? vfs_write+0xa9/0x105
[334438.931496]  [810ca3c3] ? sys_write+0x45/0x69
[334438.931503]  [810029fb] ? system_call_fastpath+0x16/0x1b


=== Flush-BTRFS ===
[334438.932351] flush-btrfs-5 R  running task 6696   366  2 0x
[334438.932361]  88003d9a3e60 0046 88003d9a3db0
81a0b020
[334438.932374]  88003d9a3dc0 8103ed23 88003d9a3fd8
00011a80
[334438.932385]  88003d9a3e60 880075672878 880075672870
88003d9a2000
[334438.932398] Call Trace:
[334438.932404]  [8103ed23] ? local_bh_enable_ip+0x9/0xb
[334438.932412]  [810e625b] ? wb_do_writeback+0x62/0x14c
[334438.932420]  [810e646a] bdi_writeback_thread+0x125/0x16f
[334438.932427]  [810e6345] ? bdi_writeback_thread+0x0/0x16f
[334438.932433]  [8104fda6] kthread+0x7d/0x85
[334438.932439]  [810037d4] kernel_thread_helper+0x4/0x10
[334438.932446]  [8104fd29] ? kthread+0x0/0x85
[334438.932452]  [810037d0] ? kernel_thread_helper+0x0/0x10



Those appeared in the log after the subvolume deletion:
[ 9089.280923] btrfs: use compression
[ 9117.763662] device label p4-openwrt devid 1 transid 2002
/dev/mapper/vgP4RAID5-openwrt
[ 9117.764087] btrfs: use compression
[ 9134.591635] 

Re: Odd mkbtrfs behavior inside of chroot

[Jérôme Poulin]

Did you try using -o bind on /proc and /sys as well? Just in case mkfs
uses /sys too, I'm not sure if /proc reacts differently to multiple
mounts or bind neither?

Envoyé de mon appareil mobile.

Jérôme Poulin
Solutions G.A.

On 2011-01-02, at 14:53, J G yoosty_...@yahoo.com wrote:

 I just encountered some odd behavior from mkbtrfs.
 The end goal is to restore a backup to newly created BTRFS partitions while 
 using the latest btrfs-tools.
 Here's the steps to what I did:
 * Booted SystemRescueCD
 * Partitioned the drives (two 750GB drives with 12 partitions each)
 * Created an extra partition on sda as a temporary holding place for the 
 backed up files and so I can update btrfs-tools
 * Formatted/mounted/restored backup files to the temporary partition which I 
 mounted on /mnt/backup
 * mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
 * chroot /mnt/backup /bin/bash
 * Updated btrfs-tools to the latest git pull from today 
 (v0.19-35-g1b444cd-dirty).
 * mkbtrfs /dev/sda5 /dev/sdb5 -L root

 mkbtrfs returned with:

 error checking /dev/sda5 mount status

 So I used strace to find out how it was checking for the mount status. Now, 
 I'm no expert here, but I'm confused as to just why it failed. The last thing 
 of note:

 lstat(/boot, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
 lstat(/boot/sysrcd.dat, 0x7fffb29681e0) = -1 ENOENT (No such file or 
 directory)
 close(3)= 0
 munmap(0x7f11df372000, 4096)= 0
 write(2, error checking /dev/sda5 mount s..., 38error checking /dev/sda5 
 mount status
 ) = 38


 doesn't explain much. I see that it's checking /proc/mounts to see what's 
 mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist 
 in the non-chrooted FS, btw).

 To make this even weirder, if I format sda5/sdb5 using the SysRescCD version 
 of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it 
 works fine.

 Any ideas here? I would expect that mkbtrfs would work inside of a chroot 
 without any assistance from the original root.

 I have the full strace from the chrooted mkbtrfs failing and from it 
 succeeding, if that's helpful.


 .:Justin:.



 --
 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: [PATCH 5/5][REPOST][BTRFS-PROGS] Add the btrfs filesystem label command

[Jérôme Poulin]

On 2010-12-05, at 12:47, Goffredo Baroncelli kreij...@inwind.it wrote:

 Hi all,

 this patch adds the command btrfs filesystem label to change (or show) the
 label of a filesystem.
 This patch is a subset of the one written previously by Morey Roof. I
 included the user space part only. So it is possible only to change/show a

label of a *single device* and *umounted* filesystem.


Personally I really don't understand why changing the label of a
mounted filesystem would cause any problem at all. Could someone
explain that to me?

Or at least the applet could include some force option for filesystem
that can't be umounted, for example, root.

Jerome
--
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: Determine if a given fs is a btrfs fs

[Jérôme Poulin]

On Sun, Oct 24, 2010 at 5:32 PM, Jérôme Poulin jeromepou...@gmail.com wrote:
...
 p4 jerome # btrfs device scan /dev/dm-22
 Scanning for Btrfs filesystems in '/dev/dm-22'
 p4 jerome # echo $?
 0
This is OK.

 p4 jerome # btrfs device scan /dev/sda
 Scanning for Btrfs filesystems in '/dev/sda'
 ERROR: unable to scan the device '/dev/sda'
 p4 jerome # echo $?
 11
...
But isn't that error misleading, btrfs scan was succesfully able to
scan /dev/sda, but, it doesn't contain btrfs, right?
--
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: [PATCH][btrfs progs] Update/clean up btrfs help and man page

[Jérôme Poulin]

On 13.09.2010 21:23, Goffredo Baroncelli wrote:
 Hi all,

 enclose you can find a patch which improve the help of the btrfs
 commands and its man page. Regarding the help of the btrfs
 command: - moved the subvolume set-default command in the
 subvolume commands group - removed a wrong new line

 Regarding the btrfs command man page: - renaming the command
 device balance in filesystem balance (thanks to Andrea Phillipp
 to highlight that) - adding the entry subvolume find-new


Could you also document the defragment switches? At the moment, they
are only documented in the code, -c to compress, -f to force and -v
for verbose (even if verbose does not add any output other than the
version).
--
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: Can you please define snapshot and subvolume?

[Jérôme Poulin]

Just to tell you one of my use case, I do compilations of OpenWRT on a
Btrfs filesystem, when I snapshot, I only snapshot the subvolume where
all the sources are instead of the whole root filesystem, and when I
need a snapshot of the root for backup purposes, only the root without
all the snapshot (which are used to compile for different models of
embedded devices) is snapshotted, which probably reduces the overhead
(I can't tell for sure) and makes deletion instantaneous, the cleaner
just wipes behind the subvolume remove command.

On Thu, Oct 7, 2010 at 7:39 AM, Francis Galiegue fgalie...@gmail.com wrote:
 I have difficulties grabbing these two concepts.

 As far as I can tell, a snapshot is an instant, synchronized,
 photography of the filesystem at a given point in time; a subvolume is
 a subroot to a btrfs filesystem.

 While I fully understand (and use) the purpose of snapshots, I don't
 quite fathom the use case for subvolumes, apart from btrfs-convert...
 Why has btrfs grown such a feature in the first place? Can someone
 give me a use case for them?

 --
 Francis Galiegue, fgalie...@gmail.com
 It seems obvious [...] that at least some 'business intelligence'
 tools invest so much intelligence on the business side that they have
 nothing left for generating SQL queries (Stéphane Faroult, in The
 Art of SQL, ISBN 0-596-00894-5)
 --
 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: patch intoducing IOctl #21 allowing for waiting for completion of deleted subvol recovery

[Jérôme Poulin]

Hi,

On Wed, Oct 6, 2010 at 11:05 AM, David Nicol davidni...@gmail.com wrote:
 The patches for btrfsctl and btrfs programs will be coming soon; I'm
 adding support for ISO8061 duration strings instead of (or in addition
 to) milliseconds and thinking about switching the order of the two
 args to btrfsctl -C from (path(default=.), ms(default=0)) to timeout
 then path, to keep it consistent with the other btrfsctl commands.
 Currently -C is special-cased in the bottom half of my btrfsctl.c
 because the path isn't the last argument.

 Btrfsctl apparently allows several operations to be presented as one
 set of command line arguments, sort of like find(1) does; would
 someone who does that a lot please respond off-list to discuss the
 ideal semantics of new commands?


The first thing I notice is that you use btrfsctl, you should base
this work on the new 'btrfs' command, which is consistant in how the
command are structured.
You could use: btrfs filesystem sync -d path  for example, it would
be like a normal sync but waits for pending '-d'eletion.
--
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: File cloning across subvolumes with BTRFS_IOC_CLONE ioctl

[Jérôme Poulin]

After pulling the new changes, I tried to do the cp --reflink=always
and still get files with no data in it.
cp --reflink=always on different subvolume: http://pastebin.com/zutMPe1h
ls -lisa on source: http://pastebin.com/8BU2Xyr5
ls -lisa on destination after trying to copy: http://pastebin.com/EPV70cD3

However, copying on the same subvolume now works perfectly, so I guess
this is fixed.

On Wed, Jul 21, 2010 at 11:32 AM, Chris Mason chris.ma...@oracle.com wrote:
 On Wed, Jul 21, 2010 at 11:11:13AM -0400, Jérôme Poulin wrote:
 I've got the same problem, and that post clearly seems to say it is possible.
 cp --reflink=always source subvolume1/   gives me:
 cp: failed to clone `': Invalid cross-device link

 Even on the same subvolume I get 10% of the files telling me the same.

 btrfs-bcp copy the files in its integrity.

 Ok, this is a bug in the ioctl.  I'll fix it up.

 -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

Re: File cloning across subvolumes with BTRFS_IOC_CLONE ioctl

[Jérôme Poulin]

Here is the real destination, I had pasted the same as source:
http://pastebin.com/nyTDeaae

On Mon, Jul 26, 2010 at 8:55 AM, Jérôme Poulin jeromepou...@gmail.com wrote:
 After pulling the new changes, I tried to do the cp --reflink=always and 
 still get files with no data in it.
 cp --reflink=always on different subvolume: http://pastebin.com/zutMPe1h
 ls -lisa on source: http://pastebin.com/8BU2Xyr5
 ls -lisa on destination after trying to copy: http://pastebin.com/EPV70cD3

 However, copying on the same subvolume now works perfectly, so I guess this 
 is fixed.

 On Wed, Jul 21, 2010 at 11:32 AM, Chris Mason chris.ma...@oracle.com wrote:
 On Wed, Jul 21, 2010 at 11:11:13AM -0400, Jérôme Poulin wrote:
 I've got the same problem, and that post clearly seems to say it is 
 possible.
 cp --reflink=always source subvolume1/   gives me:
 cp: failed to clone `': Invalid cross-device link

 Even on the same subvolume I get 10% of the files telling me the same.

 btrfs-bcp copy the files in its integrity.

 Ok, this is a bug in the ioctl.  I'll fix it up.

 -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

Re: File cloning across subvolumes with BTRFS_IOC_CLONE ioctl

[Jérôme Poulin]

I've got the same problem, and that post clearly seems to say it is possible.
cp --reflink=always source subvolume1/   gives me:
cp: failed to clone `': Invalid cross-device link

Even on the same subvolume I get 10% of the files telling me the same.

btrfs-bcp copy the files in its integrity.


On Tue, Jul 20, 2010 at 1:39 AM,  red...@gmx.com wrote:
 It seems that the BTRFS_IOC_CLONE ioctl fails when trying to do a
 cross-subvolume clone of a file. Chris Mason suggested in the past ([1])
 that this should be possible. Am I missing something?

 [1] http://kerneltrap.org/mailarchive/linux-btrfs/2010/6/10/6884911
 --
 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: [PATCH] btrfs-convert: add reiserfs support

[Jérôme Poulin]

Hello, I just want to thank you for the ReiserFS convertion patch.

Now that the semester's over, I've finally gotten around to finishing this.
Ironically, I no longer have a ReiserFS partition I want to convert :P.

On my side I had my root filesystem which has been running for quite a
while, I decided to convert it in an LVM snapshot to see if everything
is fine, seems to be, I'll be trying to convert the real filesystem
soon.

This depends on my previous four patches for btrfs-convert.

I applied the four patch, the correction to patch 2 and finally
reiserfs conversion, compiled, make convert and ran the converter,
took 10 minutes for 25GB.
All data is accessible, and seem accessible. I will try to boot it
then do the real conversion (I will first make a backup :) and let you
know!
--
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