[no subject]

trace b03c7e7060c0017c ]--- -o recovery,ro didn't help btrfs-zero-log didn't help -o recovery,ro,clear_cache after btrfs-zero-log worked Is the image of any use or should I just delete it? Thanks Michael Raskin -- To unsubscribe from this list: send the line "unsubscribe linux-

Kernel [BUG] trace on suspend.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attached find a dmesg snapshot. Configuration: Zen-kernel 2.6.31-zen5 with TuxOnIce and BtrFS, suspend from console. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Re: Btrfs warnings: -rc2

Chris Mason wrote: > > Could you please touch foo ; ls -lai foo and send us the results. Yan > Zheng has a theory that it is related to inode numbers 4873317 -rw-r--r-- 1 root root 0 Jul 17 00:29 foo dmesg is clean creating/deleting 2 files gives the same result (with even larger inodes each t

OOPS with btrfs on -rc2: trace

The same tons-of-symlinking activity [ 1104.390880] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 1104.390887] IP: [] __rb_rotate_left+0x12/0x8c [ 1104.390895] *pdpt = 34d5c001 *pde = [ 1104.390901] Oops: [#1] SMP [ 1104.390905] last sysfs file:

Btrfs warnings: -rc2

I checked the same usage scenario with -rc2 kernel.. Looks like it is just because of allmodconfig. Interesting fact, though: now warnings are thrown on on-disk operations, errors are on rbtree operations. [ 781.230303] [ cut here ] [ 781.230368] WARNING:

BTRFS warnings on the tons-of-symlinks operations

These warnings occur in the process of creating lots of symlinks before system hangs (well, this time I was luckier and system didn't hang..) I checked: when system hanged, it was always the same offset in the same function. I failed to get more good traces. I send the best I got. After lots of a

BtrFS Hangs.

Please CC me: I subscribe and get ignored by the mailing list periodically.. If other parts of the message are needed, let me know. dmesg after such a problem kills system immediately; system hangs on its own after some times. It usually happens on symlink-intensive operations (creating tens of

Re: cleanup after a small data loss on incorrect shutdown.

Chris Mason wrote: >> That's all. Reading one of the damaged file actually returned >> "Input/output error" - probably it tried to read beyond end-of-device. I >> had to kill this file (practical testing means that to continue to use >> my notebook normally I had to nuke the damaged file and get i

Re: cleanup after a small data loss on incorrect shutdown.

Chris Mason wrote: >>> I'd say to send us the btrfsck output, it will help answer these >>> questions. >> Oh, easily. "Bad block ". > > Btrfs deals in byte numbers not block numbers ;) Interesting to know. Maybe just adding "at" in the message would reduce confusion. It doesn't look like it is a

Re: cleanup after a small data loss on incorrect shutdown.

Chris Mason wrote: >> 2. I found a file which is listed in the directory, but stat on it >> returns "No such file or directory". Certainly, rm and unlink cannot >> remove it. The partition has 14G in use. What can I do to provide a >> useful piece of FS structure information? How can I remove

Re: cleanup after a small data loss on incorrect shutdown.

Chris Mason wrote: >> 2. I found a file which is listed in the directory, but stat on it >> returns "No such file or directory". Certainly, rm and unlink cannot >> remove it. The partition has 14G in use. What can I do to provide a >> useful piece of FS structure information? How can I remove

cleanup after a small data loss on incorrect shutdown.

. 3. On a 30G partition with 14G used btrfsck was left overnight. It has neither finished nor printed any meaningful request for interaction. Is it normal? Michael Raskin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord..

free space reporting - further tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I previously reported results of BTRFS synthetical tests. Now I have tried it under a real-life usage. /dev/sda6 29G 18G 12G 61% /nix/store /dev/sda6 30009388 18103372 11906016 61% /nix/st

Re: [BUG] fallocate behavior when crossing end-of-file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Edward Shishkin wrote: >> <<< >> If the offset+ len is beyond the current file size, then >> posix_fallocate() shall adjust the file size to offset+ len. Otherwise, >> the file size shall not be changed. >> > > fallocate (2) is something different

Re: [MISFEATURE] Size reporting on small devices

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Raskin wrote: > Maybe df -i could be useful until metadata/data split is flexible? Is > there any way to inspect the metadata filling up and change the split? By the way, resizing down and then up seems to help - at least I was able to

[MISFEATURE] Size reporting on small devices

data split is flexible? Is there any way to inspect the metadata filling up and change the split? Michael Raskin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKAcCIAAoJEE6tnN0aWvw3VooH/RLHZrjk4DAsAW

Re: [BUG] fallocate behavior when crossing end-of-file

ocate() shall adjust the file size to offset+ len. Otherwise, the file size shall not be changed. >>> Michael Raskin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgA