Re: btrfs: could not do orphan cleanup -116
On Mon, 2011-11-07 at 14:01 -0500, Josef Bacik wrote: On Mon, Nov 07, 2011 at 06:41:44PM +, Maciej Marcin Piechotka wrote: On Mon, 2011-11-07 at 10:29 -0500, Josef Bacik wrote: On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: Hello, When I booted my machine (after clean powerdown) the following message appeared: [ 32.757913] device fsid ---- devid 1 transid 40864 /dev/mapper/X-X [ 32.758466] btrfs: use lzo compression [ 32.758475] btrfs: enabling disk space caching [ 32.758483] btrfs: enabling inode map caching [ 32.758490] btrfs: enabling auto defrag [ 32.758497] btrfs: thread pool 2 [ 34.024359] btrfs: could not do orphan cleanup -116 [ 63.173382] btrfs: open_ctree failed btrfsck has shown no errors. Afterwards when I tried to mount filesystem it have shown: [ 116.012528] btrfs: enabling inode map caching [ 116.012534] btrfs: enabling auto defrag [ 116.012542] btrfs: thread pool 2 It looked like everything is working but to be sure I've run scrub: scrub status for fsid ---- scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 seconds total bytes scrubbed: 32.37GB with 0 errors PS. # find include | xargs grep 116 (...) include/asm-generic/errno.h:#define ESTALE 116 /* Stale NFS file handle */ (...) I don't use NFS - I use LVM on LUKS. In any case - it have been done concurrently with mounting of other fs which had no such problems. Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go away. Thanks, Josef I'm using 'newer' kernel then 3.1 - I'm following Linus' tree (this kernel is few days old). Do you have the commit a8c9e5769718d47e87cce40c9b84cab421804797 Btrfs: fix orphan cleanup regression If not then the kernel isn't new enough. Thanks, Josef It have been merged in master for 3.2-rc1 (shortly before tag). Regards -- 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: could not do orphan cleanup -116
On Wed, 2011-11-09 at 11:14 -0500, Josef Bacik wrote: On Wed, Nov 09, 2011 at 03:43:37PM +, Maciej Marcin Piechotka wrote: On Mon, 2011-11-07 at 14:01 -0500, Josef Bacik wrote: On Mon, Nov 07, 2011 at 06:41:44PM +, Maciej Marcin Piechotka wrote: On Mon, 2011-11-07 at 10:29 -0500, Josef Bacik wrote: On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: Hello, When I booted my machine (after clean powerdown) the following message appeared: [ 32.757913] device fsid ---- devid 1 transid 40864 /dev/mapper/X-X [ 32.758466] btrfs: use lzo compression [ 32.758475] btrfs: enabling disk space caching [ 32.758483] btrfs: enabling inode map caching [ 32.758490] btrfs: enabling auto defrag [ 32.758497] btrfs: thread pool 2 [ 34.024359] btrfs: could not do orphan cleanup -116 [ 63.173382] btrfs: open_ctree failed btrfsck has shown no errors. Afterwards when I tried to mount filesystem it have shown: [ 116.012528] btrfs: enabling inode map caching [ 116.012534] btrfs: enabling auto defrag [ 116.012542] btrfs: thread pool 2 It looked like everything is working but to be sure I've run scrub: scrub status for fsid ---- scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 seconds total bytes scrubbed: 32.37GB with 0 errors PS. # find include | xargs grep 116 (...) include/asm-generic/errno.h:#define ESTALE 116 /* Stale NFS file handle */ (...) I don't use NFS - I use LVM on LUKS. In any case - it have been done concurrently with mounting of other fs which had no such problems. Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go away. Thanks, Josef I'm using 'newer' kernel then 3.1 - I'm following Linus' tree (this kernel is few days old). Do you have the commit a8c9e5769718d47e87cce40c9b84cab421804797 Btrfs: fix orphan cleanup regression If not then the kernel isn't new enough. Thanks, Josef It have been merged in master for 3.2-rc1 (shortly before tag). Regards Does that mean you have that patch and are still hitting the problem? If so try this debug patch so I can see where it's coming from. Thanks, Josef No. I was just informing that it entered tree a bit later then 3.1 was released - in fact shortly before 3.2-rc1 (I presume btrfs devs not necessary remember when Linus merges changes into tree although I have no experience with kernel development). I hit it only once before updating the kernel. Best regards -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs: could not do orphan cleanup -116
Hello, When I booted my machine (after clean powerdown) the following message appeared: [ 32.757913] device fsid ---- devid 1 transid 40864 /dev/mapper/X-X [ 32.758466] btrfs: use lzo compression [ 32.758475] btrfs: enabling disk space caching [ 32.758483] btrfs: enabling inode map caching [ 32.758490] btrfs: enabling auto defrag [ 32.758497] btrfs: thread pool 2 [ 34.024359] btrfs: could not do orphan cleanup -116 [ 63.173382] btrfs: open_ctree failed btrfsck has shown no errors. Afterwards when I tried to mount filesystem it have shown: [ 116.012528] btrfs: enabling inode map caching [ 116.012534] btrfs: enabling auto defrag [ 116.012542] btrfs: thread pool 2 It looked like everything is working but to be sure I've run scrub: scrub status for fsid ---- scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 seconds total bytes scrubbed: 32.37GB with 0 errors PS. # find include | xargs grep 116 (...) include/asm-generic/errno.h:#define ESTALE 116 /* Stale NFS file handle */ (...) I don't use NFS - I use LVM on LUKS. In any case - it have been done concurrently with mounting of other fs which had no such problems. signature.asc Description: This is a digitally signed message part
Re: btrfs: could not do orphan cleanup -116
On Mon, 2011-11-07 at 10:29 -0500, Josef Bacik wrote: On Mon, Nov 07, 2011 at 01:17:04PM +, Maciej Marcin Piechotka wrote: Hello, When I booted my machine (after clean powerdown) the following message appeared: [ 32.757913] device fsid ---- devid 1 transid 40864 /dev/mapper/X-X [ 32.758466] btrfs: use lzo compression [ 32.758475] btrfs: enabling disk space caching [ 32.758483] btrfs: enabling inode map caching [ 32.758490] btrfs: enabling auto defrag [ 32.758497] btrfs: thread pool 2 [ 34.024359] btrfs: could not do orphan cleanup -116 [ 63.173382] btrfs: open_ctree failed btrfsck has shown no errors. Afterwards when I tried to mount filesystem it have shown: [ 116.012528] btrfs: enabling inode map caching [ 116.012534] btrfs: enabling auto defrag [ 116.012542] btrfs: thread pool 2 It looked like everything is working but to be sure I've run scrub: scrub status for fsid ---- scrub started at Mon Nov 7 13:05:50 2011 and finished after 606 seconds total bytes scrubbed: 32.37GB with 0 errors PS. # find include | xargs grep 116 (...) include/asm-generic/errno.h:#define ESTALE 116 /* Stale NFS file handle */ (...) I don't use NFS - I use LVM on LUKS. In any case - it have been done concurrently with mounting of other fs which had no such problems. Yeah that's a bug with an earlier kernel, if you upgrade to 3.1 it should go away. Thanks, Josef I'm using 'newer' kernel then 3.1 - I'm following Linus' tree (this kernel is few days old). Regards -- 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 default subvolume, /home
On Sat, 2011-11-05 at 22:22 -0400, Eric Griffith wrote: Hey guys, I've been trying out BTRFS the last couple days, just to kind of see what to expect and what I can do with it once its finalized and we have a working fsck. I do have a couple question that neither the Arch Wiki, The Fedora WIki, Ubuntu wiki or the kernel.org wiki could answer. So here goes; When I installed fedora (F16 Beta) I made root be an ext4 partition, with /home as BTRFS. Ubuntu wiki states that any BTRFS partition has a default subvolume called default, I cant find it for /home. /etc/fstab: # # /etc/fstab # Created by anaconda on Thu Nov 3 15:24:14 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=e5021a48-c961-4e73-98a5-beee06355f46 / ext4 defaults 1 1 UUID=97ac420f-2818-4833-b7b6-4ac497716e3b /home btrfs defaults,autodefrag,compress 1 2 UUID=0d275462-1ad3-46af-a1b8-637ca5efeca6 swap swap defaults 0 0 btrfs --help says. btrfs subvolume list path : List the snapshot/subvolume of a filesystem. I'd expect it to spit out default at some point. Couple outputs [eric@eric-laptop ~]$ sudo btrfs subvolume list / ERROR: '/' is not a subvolume [eric@eric-laptop ~]$ sudo btrfs subvolume list /home [eric@eric-laptop ~]$ It doesn't list the root volume (0). I'm not sure if it ever did - it is root volume so it might not subvolume. What i wanted was an easy; reliable way to keep a backup of my home using btrfs instead of just rsync. Unfortunately, in order to use snapshot, it needs to be on, or be a, subvolume. Remember that snapshots are not backups. If anything damages your partition, or even sector your file is in, you have troubles. proof: [eric@eric-laptop ~]$ sudo btrfs subvolume snapshot /home/eric /home/eric/test ERROR: '/home/eric' is not a subvolume [eric@eric-laptop ~]$ Why not (with eric back on /home): btrfs subvolume snapshot /home /home/snapshot-$(date -u +%Y%m%d) Snapshots are not recursive. (It works for me with integration-20111030 but not integration-20111012 on 3.1.0+) So; I rebooted into single user, mv'ed /home/eric to /home/eric-btrfs, made a subvolume in /home/ named 'eric' to take the place of my home, and cp'ed all of my files from eric-btrfs to eric, a quick chown, and chmod to get the file permissions right. Rebooted, tried to login... error messages, lots of error messages. Cant switch out from / /home/eric/.kde/share/config/knotifyrc is not writable despite having read and write permission, and ownership. Can you log in from tty to check whether you can access $HOME? I'm not btrfs developer but I am not sure if you can have subvolume owned by non-root. Can anyone figure out what the heck is going on? I know BTRFS is still experimental, but I thought the layout and implementation was finalized. OR; what do I have to do to make Btrfs work as a /home as it should? (see ZFS / LVM ) Regards signature.asc Description: This is a digitally signed message part
Re: is space really freed after deleting large subvolume?
On Thu, 2011-10-13 at 23:03 +0200, krz...@gmail.com wrote: If you delete a large number of files, then there is no avoiding the fact that a lot of metadata needs to be updated. In this respect btrfs is unlikely to be significantly faster than any other filing system. Are you sure? That would mean that instant deletion of subvolume in btrfs is actualy taking ??SAME?? time and io power in BACKGROUND like deleting by rm -rf in any filesystem. Common misconception would be that subvolume deletion is much more efficient and near zero time consuming. I think it is very important to clear that up. I may be wrong but it may not be necessary true - the fs may optimize the deletion so for example if 2 files shares the same extend it is updated once (it may be beneficial as cost of I/O is bigger then cost of CPU). Additionally it means that the btrfs does things asynchronously and we don't need to wait for all cleanup (I assume that it is as soon as the deletion is commited to log). Therefore if deletion takes 100 ms of i/o and 10 ms of cpu on other fs and 100 ms of i/o and 20 ms of cpu on btrfs the following code takes 210 ms vs. 120 ms on btrfs in very simplified model. unlink(/btrfs/file); busy_wait(100); // Simulates 100 ms computation Regards PS. I'm not btrfs developer but I see at least potential advantages of asynchronous deletion (or split deletion in 2-phases). I don't know how much is implemented. signature.asc Description: This is a digitally signed message part
Re: Regression in btrfs-next: BUG at fs/btrfs/super.c:984!
On Sun, 2011-10-02 at 19:39 +0200, David Sterba wrote:
On Sat, Oct 01, 2011 at 11:43:10PM +0200, Maciej Marcin Piechotka wrote:
PS. It might happened that it was caused by parition mounted read-only
on read-only block device.
^^^
This is the key information!
super.c: btrfs_calc_avail_data_space()
983 nr_devices = fs_info-fs_devices-rw_devices;
984 BUG_ON(!nr_devices);
If there are no writable devices, this BUGON fires, although this case
in connection with RO mount is handled elsewhere properly.
This is called through sysfs and just tries to obtain available free
space information to print it. I think the BUG_ON is not necessary here
and the function can take a short track returning 0 as available free
space:
if (!nr_devices) {
*free_bytes = 0;
return 0;
}
I could be possible to actually read the free space even from a RO
device (be it RO mount or not), but I don't see much benefit which would
justify the work.
Can you please test the fix and let us know if the statfs number look
reasonable?
david
Well - it shows size 50G, used 29G and avail 0G in df -h.
Regards
signature.asc
Description: This is a digitally signed message part
Regression in btrfs-next: BUG at fs/btrfs/super.c:984!
After merging btrfs-next patches (chris' btrfs-3.0 branch) I get following error: [ 9799.199495] [ cut here ] [ 9799.199511] kernel BUG at fs/btrfs/super.c:984! [ 9799.199524] invalid opcode: [#1] PREEMPT SMP [ 9799.199539] CPU 1 [ 9799.199542] Modules linked in: cpufreq_stats btrfs zlib_deflate libcrc32c microcode reiserfs arc4 snd_hda_codec_conexant uvcvideo cdc_ether usbnet videodev v4l2_compat_ioctl32 cdc_acm cdc_wdm btusb snd_hda_intel iwlagn bluetooth mac80211 snd_hda_codec snd_hwdep snd_pcm cfg80211 snd_timer snd soundcore snd_page_alloc e1000e thinkpad_acpi hwmon rfkill nvram zcache(PC) zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm loop configs ipv6 autofs4 uhci_hcd firewire_ohci sdhci_pci firewire_core sr_mod ehci_hcd sdhci mmc_core crc_itu_t cdrom sd_mod usbcore [ 9799.199657] [ 9799.199669] Pid: 2263, comm: df Tainted: P C 3.0.4-ck1+ #1 LENOVO 2242CTO/2242CTO [ 9799.199686] RIP: 0010:[a032b682] [a032b682] btrfs_statfs+0x108/0x3a9 [btrfs] [ 9799.199716] RSP: 0018:8800414f9de8 EFLAGS: 00010246 [ 9799.199728] RAX: 880129bf8000 RBX: 8800414f9f00 RCX: 880129bfa30c [ 9799.199742] RDX: 880129c8e240 RSI: 9123683e RDI: [ 9799.199756] RBP: 880129bf8000 R08: 810d1ad0 R09: 0203 [ 9799.199769] R10: 88012254eab0 R11: 0203 R12: 88011ba433c0 [ 9799.199783] R13: R14: 00885fa0 R15: 880129bfa368 [ 9799.199797] FS: 7f15983f7700() GS:88013bc8() knlGS: [ 9799.199811] CS: 0010 DS: ES: CR0: 80050033 [ 9799.199824] CR2: 015fa008 CR3: 8e5d5000 CR4: 000406e0 [ 9799.199838] DR0: DR1: DR2: [ 9799.199851] DR3: DR6: 0ff0 DR7: 0400 [ 9799.199865] Process df (pid: 2263, threadinfo 8800414f8000, task 8800b8426780) [ 9799.199878] Stack: [ 9799.199889] 8800414f9ed8 810d1ad0 88013162e4f8 [ 9799.199906] 880129f3c900 88012cdf3800 880129bf8000 000c430fe005 [ 9799.199923] 880132b0f540 88011badc958 880129bfa3c0 [ 9799.199940] Call Trace: [ 9799.199955] [810d1ad0] ? user_path_at+0x55/0x7b [ 9799.199971] [810e5f2c] ? statfs_by_dentry+0x46/0x5d [ 9799.199985] [810e5f56] ? vfs_statfs+0x13/0x8b [ 9799.19] [810d1ad0] ? user_path_at+0x55/0x7b [ 9799.26] [810e5ffe] ? user_statfs+0x30/0x48 [ 9799.26] [810e6068] ? sys_statfs+0x12/0x2b [ 9799.26] [8136607b] ? system_call_fastpath+0x16/0x1b [ 9799.26] Code: 18 48 89 33 4c 89 6b 20 48 89 43 08 48 8b 44 24 28 48 8b 80 20 01 00 00 48 8b 90 b8 23 00 00 48 89 44 24 30 8b 7a 30 85 ff 75 02 0f 0b 48 63 ff be 50 00 00 00 48 89 54 24 20 48 c1 e7 05 e8 56 [ 9799.26] RIP [a032b682] btrfs_statfs+0x108/0x3a9 [btrfs] [ 9799.26] RSP 8800414f9de8 [ 9799.221655] ---[ end trace 327e64ade405e154 ]--- PS. It might happened that it was caused by parition mounted read-only on read-only block device. signature.asc Description: This is a digitally signed message part
Re: Still can't access wiki for btrfs; anybody have a copy of the documentation source?
On Wed, 2011-09-21 at 16:37 -0400, Anadon wrote: Hello all, I'm trying to look into working on some few features for a filesystem, and figured that if they were to be adopted, better work on the current project. I'm looking for the standard documentaion, and a copy of the source. I have no idea where to look for these since everything still points to kernel.org, and as of this mailing, is still not accessible. -- 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 http://web.archive.org/web/20110720220640/https://btrfs.wiki.kernel.org/index.php/Main_Page Regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Mon, 2011-09-19 at 02:44 +0200, Maciej Marcin Piechotka wrote: On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote: Unfortunately it results in freeze of system and I cannot give more details. Sometimes it happens not from fcron but then it does not result in freeze (???). Could you give me the method to reproduce it? Thanks Miao Sorry for spamming in this thread but I'm trying to post my findings in hope that somebody will understand what's going on. Recent crash gave some valuable information IMHO: 1. I started the autocompletion of path in zsh 2. At some point the zsh hanged. In ps the process was listed as runnable 3. Any access to root volume (the one that zsh was trying to readdir) finished in hang. 4. I was able to access the child volume (/home) 5. After some time the bug is hit. At this time strange things happens (screen freeze etc.). I guess that there is some strange interaction between KMS, X and now-hanged composite manager Next time it happend (also during listing root directory of volume 0) I observed the following thing - I can log out and unmount home but the volume 0 remains busy and cannot be unmounted. Things to consider: - It is not enabled/disabled by any mount option - Is it triggered when the parent volume (say volume 0) and child volume are both mounted? I cannot reproduce it when the parent volume is not mounted (snapshots are to subvolume) - Which case is it failing (I've tried to add printk but I cannot find the option in printk to print u64) - Why it happens only during night? Regards Regards signature.asc Description: This is a digitally signed message part
Re: Inefficient storing of ISO images with compress=lzo
On Mon, 2011-09-19 at 10:53 +0800, Li Zefan wrote: Maciej Marcin Piechotka wrote: I've noticed that: - with x86-64 Fedora 15 DVD install images: - du -sh ROOT VOLUME was 36 GB - btrfs df | grep -i data have shown over 40 GB used - without - du -sh ROOT VOLUME is 34 GB - btrfs df | grep -i data have shown less then 34 GB used It seems that iso files are considered compressable while they may not be (and penalty is severe - 3x). With compress option specified, btrfs will try to compress the file, at most 128K at one time, and if the compressed result is not smaller, the file will be marked as uncompressable. I just tried with Fedora-14-i386-DVD.iso, and the first 896K is compressed, with a compress ratio about 71.7%, and the remaining data is not compressed. -- Li Zefan Just a question from person who don't know how btrfs operates - what if the beginning of file is well compressable and the rest is not? In any case the compression was my uneducated guess where is missing 4GB. Regards -- 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 vs data deduplication
On Sat, 2011-07-09 at 08:19 +0200, Paweł Brodacki wrote: Hello, I've stumbled upon this article: http://storagemojo.com/2011/06/27/de-dup-too-much-of-good-thing/ Reportedly Sandforce SF1200 SSD controller does internally block-level data de-duplication. This effectively removes the additional protection given by writing multiple metadata copies. This technique may be used, or can be used in the future by manufactureres of other drives too. I would like to ask, if the metadata copies written to a btrfs system with enabled metadata mirroring are identical, or is there something that makes them unique on-disk, therefore preventing their de-duplication. I tried googling for the answer, but didn't net anything that would answer my question. If the metadata copies are identical, I'd like to ask if it would be possible to change this without major disruption? I know that changes to on-disk format aren't a thing made lightly, but I'd be grateful for any comments. The increase of the risk of file system corruption introduced by data de-duplication on Sandforce controllers was down-played in the vendor's reply included in the article, but still, what's the point of duplicating metadata on file system level, if storage below can remove that redundancy? Regards, Paweł Hello, Sorry I add my 0.03$. It is possible to workaround it by using encryption. If something other then ebc is used the identical elements in unecrypted mode are stored as different on hdd. The drawbacks: - Encryption overhead (you may want to use non-secure mode as you're not interested in security) - There is avalanche effect (whole [encryption] block gets corrupted even if one bit of block is corrupted). Regards signature.asc Description: This is a digitally signed message part
Inefficient storing of ISO images with compress=lzo
I've noticed that: - with x86-64 Fedora 15 DVD install images: - du -sh ROOT VOLUME was 36 GB - btrfs df | grep -i data have shown over 40 GB used - without - du -sh ROOT VOLUME is 34 GB - btrfs df | grep -i data have shown less then 34 GB used It seems that iso files are considered compressable while they may not be (and penalty is severe - 3x). Regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote: Unfortunately it results in freeze of system and I cannot give more details. Sometimes it happens not from fcron but then it does not result in freeze (???). Could you give me the method to reproduce it? Thanks Miao Sorry for spamming in this thread but I'm trying to post my findings in hope that somebody will understand what's going on. Recent crash gave some valuable information IMHO: 1. I started the autocompletion of path in zsh 2. At some point the zsh hanged. In ps the process was listed as runnable 3. Any access to root volume (the one that zsh was trying to readdir) finished in hang. 4. I was able to access the child volume (/home) 5. After some time the bug is hit. At this time strange things happens (screen freeze etc.). I guess that there is some strange interaction between KMS, X and now-hanged composite manager Next time it happend (also during listing root directory of volume 0) I observed the following thing - I can log out and unmount home but the volume 0 remains busy and cannot be unmounted. Things to consider: - It is not enabled/disabled by any mount option - Is it triggered when the parent volume (say volume 0) and child volume are both mounted? - Which case is it failing (I've tried to add printk but I cannot find the option in printk to print u64) - Why it happens only during night? Regards -- 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/inode.c:2299
1. Once the blank screen happened ot 23:00 UTC instead of 03:00 UTC 2. I tried to disable the caches 3. I tried to rsync via ext3 + btrfs-convert. I noticed something - in old fs the df looked like: Data: total=30.01GB, used=28.42GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=199.47MB Metadata: total=8.00MB, used=0.00 on new one (with ext3 image): Data: total=33.33GB, used=20.52GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=11.36GB and without: Data: total=33.33GB, used=20.04GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=10.88GB Given that lzo compression was used about 4 GB data difference was expected (difference depending on mount options on rsynbc). However: 1. What is DUP? 2. Why metadata is so big on convertion from ext3 while data is small (the sum is about right - 31GB vs 28.5GB)? Regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Sat, 2011-09-17 at 20:25 +0200, Maciej Marcin Piechotka wrote: 1. Once the blank screen happened ot 23:00 UTC instead of 03:00 UTC 2. I tried to disable the caches 3. I tried to rsync via ext3 + btrfs-convert. I noticed something - in old fs the df looked like: Data: total=30.01GB, used=28.42GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=199.47MB Metadata: total=8.00MB, used=0.00 on new one (with ext3 image): Data: total=33.33GB, used=20.52GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=11.36GB and without: Data: total=33.33GB, used=20.04GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=10.88GB Given that lzo compression was used about 4 GB data difference was expected (difference depending on mount options on rsynbc). However: 1. What is DUP? 2. Why metadata is so big on convertion from ext3 while data is small (the sum is about right - 31GB vs 28.5GB)? That should be a) b) 4. I think it triggered a bug with data loss - the new data was not written to disk despite being visible from userspace after mount during the same mount. Regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Sat, 2011-09-17 at 20:30 +0200, Maciej Marcin Piechotka wrote: On Sat, 2011-09-17 at 20:25 +0200, Maciej Marcin Piechotka wrote: 1. Once the blank screen happened ot 23:00 UTC instead of 03:00 UTC 2. I tried to disable the caches 3. I tried to rsync via ext3 + btrfs-convert. I noticed something - in old fs the df looked like: Data: total=30.01GB, used=28.42GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=199.47MB Metadata: total=8.00MB, used=0.00 on new one (with ext3 image): Data: total=33.33GB, used=20.52GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=11.36GB and without: Data: total=33.33GB, used=20.04GB System: total=32.00MB, used=4.00KB Metadata: total=16.64GB, used=10.88GB Given that lzo compression was used about 4 GB data difference was expected (difference depending on mount options on rsynbc). However: 1. What is DUP? Ok.After some digging I found out. 2. Why metadata is so big on convertion from ext3 while data is small (the sum is about right - 31GB vs 28.5GB)? After rebalancing I got: Data: total=32.00GB, used=30.83GB System: total=32.00MB, used=12.00KB Metadata: total=1.00GB, used=227.16MB That should be a) b) 4. I think it triggered a bug with data loss - the new data was not written to disk despite being visible from userspace after mount during the same mount. Regards signature.asc Description: This is a digitally signed message part
Re: Rename BTRfs to MuchSlowerFS ?
On Fri, 2011-09-16 at 05:16 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 2:37 AM, Felix Blanke felixbla...@gmail.com wrote: I'm using btrfs since one year now and it's quite fast. I don't feel any differences to other filesystems. Never tried a benchmark but for my daily work it's nice. Your workload must be light :) I recently repeatedly rsync whole partitions (30GB) without ill effects. (ok - first sync took whole 1s). The advantage to ext4 for me is the build in raid1 and the snapshots. I'm using the snapshot feature for my local backups. I like it because it's really easy and uses very few storage. A simple Snapshot - Rsync to a different disk - Snapshot script is the perfect local backup method. you've never used zfs have you :) For that purpose, think same feature as btrfs snapshot + rsync but without needing rsync. This can be very useful as the process of rsync determining what data to transfer can be quite CPU/disk intensive. Now I'm curious - how do zsf get data off the partition without rsync? Regards signature.asc Description: This is a digitally signed message part
Re: Rename BTRfs to MuchSlowerFS ?
On Fri, 2011-09-16 at 13:42 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 1:21 PM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Fri, 2011-09-16 at 05:16 +0700, Fajar A. Nugraha wrote: On Fri, Sep 16, 2011 at 2:37 AM, Felix Blanke felixbla...@gmail.com wrote: I'm using btrfs since one year now and it's quite fast. I don't feel any differences to other filesystems. Never tried a benchmark but for my daily work it's nice. Your workload must be light :) I recently repeatedly rsync whole partitions (30GB) without ill effects. (ok - first sync took whole 1s). Wait, you mean you sync 30GB data to another partition in one second? It should not be possible for single HDD no matter what the filesystem is. Unless you're using SSD or many HDD in raid. You misparse the sentence. First sync took 1s after rsync and next were much faster. Regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote: On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote: I receive the bug when I try to snapshot from fcron: 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76] [ cut here ] 2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kernel BUG at fs/btrfs/inode.c:2299! 2011-08-29T02:00:46.529256+01:00 picard kernel: [ 4155.98] invalid opcode: [#1] PREEMPT SMP 2011-08-29T02:00:46.529259+01:00 picard kernel: [ 4155.444506] CPU 1 2011-08-29T02:00:46.529264+01:00 picard kernel: [ 4155.444508] Modules linked in: microcode reiserfs btrfs zlib_deflate libcrc32c arc4 snd_hda_codec_conexant iwlagn mac80211 uvcvideo videodev v4l2_compat_ioctl32 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd thinkpad_acpi soundcore snd_page_alloc hwmon rfkill nvram e1000e zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm configs ipv6 autofs4 usbhid uhci_hcd firewire_ohci firewire_core sdhci_pci ehci_hcd crc_itu_t sdhci mmc_core sd_mod usbcore sr_mod cdrom 2011-08-29T02:00:46.529267+01:00 picard kernel: [ 4155.444569] 2011-08-29T02:00:46.529270+01:00 picard kernel: [ 4155.444576] Pid: 3167, comm: btrfs Tainted: P C 3.0.3-gentoo #1 LENOVO 2242CTO/2242CTO 2011-08-29T02:00:46.529274+01:00 picard kernel: [ 4155.444586] RIP: 0010:[a031339b] [a031339b] btrfs_orphan_del +0x8d/0xa9 [btrfs] 2011-08-29T02:00:46.529276+01:00 picard kernel: [ 4155.444611] RSP: :880111c21b58 EFLAGS: 00010282 2011-08-29T02:00:46.529279+01:00 picard kernel: [ 4155.444619] RAX: fffe RBX: 88011141bd60 RCX: 1000 2011-08-29T02:00:46.529289+01:00 picard kernel: [ 4155.444626] RDX: 000f RSI: 880110c8d250 RDI: 880134092d80 2011-08-29T02:00:46.529292+01:00 picard kernel: [ 4155.444634] RBP: R08: 880111c21a30 R09: 0011 2011-08-29T02:00:46.529297+01:00 picard kernel: [ 4155.444642] R10: 01dc R11: 0286 R12: 880136866300 2011-08-29T02:00:46.529299+01:00 picard kernel: [ 4155.444650] R13: 880130cac800 R14: 0001 R15: 880130cacb88 2011-08-29T02:00:46.529302+01:00 picard kernel: [ 4155.444658] FS: 7f126715a740() GS:88013bc8() knlGS: 2011-08-29T02:00:46.529304+01:00 picard kernel: [ 4155.444666] CS: 0010 DS: ES: CR0: 8005003b 2011-08-29T02:00:46.529307+01:00 picard kernel: [ 4155.444673] CR2: 7f5149eb7008 CR3: 9caca000 CR4: 000406e0 2011-08-29T02:00:46.529309+01:00 picard kernel: [ 4155.444681] DR0: DR1: DR2: 2011-08-29T02:00:46.529311+01:00 picard kernel: [ 4155.444689] DR3: DR6: 0ff0 DR7: 0400 2011-08-29T02:00:46.529314+01:00 picard kernel: [ 4155.444697] Process btrfs (pid: 3167, threadinfo 880111c2, task 88010b35a140) 2011-08-29T02:00:46.529316+01:00 picard kernel: [ 4155.444705] Stack: 2011-08-29T02:00:46.529318+01:00 picard kernel: [ 4155.444711] 00c369c5 880130cac800 880110c8dbe0 00c369c5 2011-08-29T02:00:46.529321+01:00 picard kernel: [ 4155.444720] 880130cacb88 880130cacb90 a03173c4 2011-08-29T02:00:46.562822+01:00 picard kernel: [ 4155.444730] 880136866300 88011141bd60 880110c8dbe0 fffb 2011-08-29T02:00:46.562959+01:00 picard kernel: [ 4155.444739] Call Trace: 2011-08-29T02:00:46.562964+01:00 picard kernel: [ 4155.444756] [a03173c4] ? btrfs_orphan_cleanup+0x196/0x2d9 [btrfs] 2011-08-29T02:00:46.562966+01:00 picard kernel: [ 4155.444773] [a0317862] ? btrfs_lookup_dentry+0x35b/0x392 [btrfs] 2011-08-29T02:00:46.562969+01:00 picard kernel: [ 4155.444790] [a03178a2] ? btrfs_lookup+0x9/0x1f [btrfs] 2011-08-29T02:00:46.562971+01:00 picard kernel: [ 4155.444801] [810ccf63] ? d_alloc_and_lookup+0x3a/0x60 2011-08-29T02:00:46.562973+01:00 picard kernel: [ 4155.444810] [810ce356] ? walk_component+0x210/0x3b7 2011-08-29T02:00:46.562975+01:00 picard kernel: [ 4155.444818] [810cea4a] ? path_lookupat+0x7c/0x29e 2011-08-29T02:00:46.562979+01:00 picard kernel: [ 4155.444827] [810cfc34] ? do_path_lookup+0x1c/0x87 2011-08-29T02:00:46.562981+01:00 picard kernel: [ 4155.444835] [810cffe2] ? user_path_at+0x49/0x7b 2011-08-29T02:00:46.562983+01:00 picard kernel: [ 4155.444843] [810c8781] ? vfs_fstatat+0x3c/0x6a 2011-08-29T02:00:46.562986+01:00 picard kernel: [ 4155.444853] [8102d38e] ? sub_preempt_count+0x83/0x94 2011-08-29T02:00:46.562988+01:00 picard kernel: [ 4155.444861] [810c88ab] ? sys_newstat+0x12/0x2b 2011-08-29T02:00:46.562990+01:00 picard kernel: [ 4155.444870
Re: kernel BUG at fs/btrfs/inode.c:2299
On Fri, 2011-09-09 at 09:02 +0600, Roman Mamedov wrote: On Fri, 09 Sep 2011 02:13:38 +0100 Maciej Marcin Piechotka uzytkown...@gmail.com wrote: c) It usually happens a few minutes past 3 UTC. I have no idea what is casuing this but it is consistent. Did you check if your /etc/crontab or /etc/cron.d/* have anything scheduled for that time? It does: - logrotate (configured to do it weekly in /etc/logrotate) - makewhatis -u Neither of which should touch /home. Before it snapshotted the volume and I thought it was the direct cause. Best regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Fri, 2011-09-02 at 12:18 +0100, Maciej Marcin Piechotka wrote: On Tue, 2011-08-30 at 09:47 +0100, Maciej Marcin Piechotka wrote: On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote: On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote: I receive the bug when I try to snapshot from fcron: 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76] [ cut here ] 2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kernel BUG at fs/btrfs/inode.c:2299! 2011-08-29T02:00:46.529256+01:00 picard kernel: [ 4155.98] invalid opcode: [#1] PREEMPT SMP 2011-08-29T02:00:46.529259+01:00 picard kernel: [ 4155.444506] CPU 1 2011-08-29T02:00:46.529264+01:00 picard kernel: [ 4155.444508] Modules linked in: microcode reiserfs btrfs zlib_deflate libcrc32c arc4 snd_hda_codec_conexant iwlagn mac80211 uvcvideo videodev v4l2_compat_ioctl32 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd thinkpad_acpi soundcore snd_page_alloc hwmon rfkill nvram e1000e zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm configs ipv6 autofs4 usbhid uhci_hcd firewire_ohci firewire_core sdhci_pci ehci_hcd crc_itu_t sdhci mmc_core sd_mod usbcore sr_mod cdrom 2011-08-29T02:00:46.529267+01:00 picard kernel: [ 4155.444569] 2011-08-29T02:00:46.529270+01:00 picard kernel: [ 4155.444576] Pid: 3167, comm: btrfs Tainted: P C 3.0.3-gentoo #1 LENOVO 2242CTO/2242CTO 2011-08-29T02:00:46.529274+01:00 picard kernel: [ 4155.444586] RIP: 0010:[a031339b] [a031339b] btrfs_orphan_del +0x8d/0xa9 [btrfs] 2011-08-29T02:00:46.529276+01:00 picard kernel: [ 4155.444611] RSP: :880111c21b58 EFLAGS: 00010282 2011-08-29T02:00:46.529279+01:00 picard kernel: [ 4155.444619] RAX: fffe RBX: 88011141bd60 RCX: 1000 2011-08-29T02:00:46.529289+01:00 picard kernel: [ 4155.444626] RDX: 000f RSI: 880110c8d250 RDI: 880134092d80 2011-08-29T02:00:46.529292+01:00 picard kernel: [ 4155.444634] RBP: R08: 880111c21a30 R09: 0011 2011-08-29T02:00:46.529297+01:00 picard kernel: [ 4155.444642] R10: 01dc R11: 0286 R12: 880136866300 2011-08-29T02:00:46.529299+01:00 picard kernel: [ 4155.444650] R13: 880130cac800 R14: 0001 R15: 880130cacb88 2011-08-29T02:00:46.529302+01:00 picard kernel: [ 4155.444658] FS: 7f126715a740() GS:88013bc8() knlGS: 2011-08-29T02:00:46.529304+01:00 picard kernel: [ 4155.444666] CS: 0010 DS: ES: CR0: 8005003b 2011-08-29T02:00:46.529307+01:00 picard kernel: [ 4155.444673] CR2: 7f5149eb7008 CR3: 9caca000 CR4: 000406e0 2011-08-29T02:00:46.529309+01:00 picard kernel: [ 4155.444681] DR0: DR1: DR2: 2011-08-29T02:00:46.529311+01:00 picard kernel: [ 4155.444689] DR3: DR6: 0ff0 DR7: 0400 2011-08-29T02:00:46.529314+01:00 picard kernel: [ 4155.444697] Process btrfs (pid: 3167, threadinfo 880111c2, task 88010b35a140) 2011-08-29T02:00:46.529316+01:00 picard kernel: [ 4155.444705] Stack: 2011-08-29T02:00:46.529318+01:00 picard kernel: [ 4155.444711] 00c369c5 880130cac800 880110c8dbe0 00c369c5 2011-08-29T02:00:46.529321+01:00 picard kernel: [ 4155.444720] 880130cacb88 880130cacb90 a03173c4 2011-08-29T02:00:46.562822+01:00 picard kernel: [ 4155.444730] 880136866300 88011141bd60 880110c8dbe0 fffb 2011-08-29T02:00:46.562959+01:00 picard kernel: [ 4155.444739] Call Trace: 2011-08-29T02:00:46.562964+01:00 picard kernel: [ 4155.444756] [a03173c4] ? btrfs_orphan_cleanup+0x196/0x2d9 [btrfs] 2011-08-29T02:00:46.562966+01:00 picard kernel: [ 4155.444773] [a0317862] ? btrfs_lookup_dentry+0x35b/0x392 [btrfs] 2011-08-29T02:00:46.562969+01:00 picard kernel: [ 4155.444790] [a03178a2] ? btrfs_lookup+0x9/0x1f [btrfs] 2011-08-29T02:00:46.562971+01:00 picard kernel: [ 4155.444801] [810ccf63] ? d_alloc_and_lookup+0x3a/0x60 2011-08-29T02:00:46.562973+01:00 picard kernel: [ 4155.444810] [810ce356] ? walk_component+0x210/0x3b7 2011-08-29T02:00:46.562975+01:00 picard kernel: [ 4155.444818] [810cea4a] ? path_lookupat+0x7c/0x29e 2011-08-29T02:00:46.562979+01:00 picard kernel: [ 4155.444827] [810cfc34] ? do_path_lookup+0x1c/0x87 2011-08-29T02:00:46.562981+01:00 picard kernel: [ 4155.444835] [810cffe2] ? user_path_at+0x49/0x7b 2011-08-29T02:00:46.562983+01:00 picard kernel: [ 4155.444843] [810c8781] ? vfs_fstatat+0x3c/0x6a 2011-08
Problems with tuxonice and btrfs
I get filesystem corruption when I unsuccessfully hibernate using tuxonice. I don't get this problem using standard suspend. While I understand TOI is not in mainline it requires no modification for non-FUSE filesystems. where should I report the problem? Best regards signature.asc Description: This is a digitally signed message part
Re: kernel BUG at fs/btrfs/inode.c:2299
On Tue, 2011-08-30 at 09:47 +0100, Maciej Marcin Piechotka wrote:
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote:
On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote:
I receive the bug when I try to snapshot from fcron:
2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76]
[ cut here ]
2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kernel
BUG at fs/btrfs/inode.c:2299!
2011-08-29T02:00:46.529256+01:00 picard kernel: [ 4155.98] invalid
opcode: [#1] PREEMPT SMP
2011-08-29T02:00:46.529259+01:00 picard kernel: [ 4155.444506] CPU 1
2011-08-29T02:00:46.529264+01:00 picard kernel: [ 4155.444508] Modules
linked in: microcode reiserfs btrfs zlib_deflate libcrc32c arc4
snd_hda_codec_conexant iwlagn mac80211 uvcvideo videodev
v4l2_compat_ioctl32 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep
snd_pcm snd_timer snd thinkpad_acpi soundcore snd_page_alloc hwmon
rfkill nvram e1000e zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse
fscache kvm_intel kvm configs ipv6 autofs4 usbhid uhci_hcd firewire_ohci
firewire_core sdhci_pci ehci_hcd crc_itu_t sdhci mmc_core sd_mod usbcore
sr_mod cdrom
2011-08-29T02:00:46.529267+01:00 picard kernel: [ 4155.444569]
2011-08-29T02:00:46.529270+01:00 picard kernel: [ 4155.444576] Pid:
3167, comm: btrfs Tainted: P C 3.0.3-gentoo #1 LENOVO
2242CTO/2242CTO
2011-08-29T02:00:46.529274+01:00 picard kernel: [ 4155.444586] RIP:
0010:[a031339b] [a031339b] btrfs_orphan_del
+0x8d/0xa9 [btrfs]
2011-08-29T02:00:46.529276+01:00 picard kernel: [ 4155.444611] RSP:
:880111c21b58 EFLAGS: 00010282
2011-08-29T02:00:46.529279+01:00 picard kernel: [ 4155.444619] RAX:
fffe RBX: 88011141bd60 RCX: 1000
2011-08-29T02:00:46.529289+01:00 picard kernel: [ 4155.444626] RDX:
000f RSI: 880110c8d250 RDI: 880134092d80
2011-08-29T02:00:46.529292+01:00 picard kernel: [ 4155.444634] RBP:
R08: 880111c21a30 R09: 0011
2011-08-29T02:00:46.529297+01:00 picard kernel: [ 4155.444642] R10:
01dc R11: 0286 R12: 880136866300
2011-08-29T02:00:46.529299+01:00 picard kernel: [ 4155.444650] R13:
880130cac800 R14: 0001 R15: 880130cacb88
2011-08-29T02:00:46.529302+01:00 picard kernel: [ 4155.444658] FS:
7f126715a740() GS:88013bc8() knlGS:
2011-08-29T02:00:46.529304+01:00 picard kernel: [ 4155.444666] CS: 0010
DS: ES: CR0: 8005003b
2011-08-29T02:00:46.529307+01:00 picard kernel: [ 4155.444673] CR2:
7f5149eb7008 CR3: 9caca000 CR4: 000406e0
2011-08-29T02:00:46.529309+01:00 picard kernel: [ 4155.444681] DR0:
DR1: DR2:
2011-08-29T02:00:46.529311+01:00 picard kernel: [ 4155.444689] DR3:
DR6: 0ff0 DR7: 0400
2011-08-29T02:00:46.529314+01:00 picard kernel: [ 4155.444697] Process
btrfs (pid: 3167, threadinfo 880111c2, task 88010b35a140)
2011-08-29T02:00:46.529316+01:00 picard kernel: [ 4155.444705] Stack:
2011-08-29T02:00:46.529318+01:00 picard kernel: [ 4155.444711]
00c369c5 880130cac800 880110c8dbe0 00c369c5
2011-08-29T02:00:46.529321+01:00 picard kernel: [ 4155.444720]
880130cacb88 880130cacb90 a03173c4
2011-08-29T02:00:46.562822+01:00 picard kernel: [ 4155.444730]
880136866300 88011141bd60 880110c8dbe0 fffb
2011-08-29T02:00:46.562959+01:00 picard kernel: [ 4155.444739] Call
Trace:
2011-08-29T02:00:46.562964+01:00 picard kernel: [ 4155.444756]
[a03173c4] ? btrfs_orphan_cleanup+0x196/0x2d9 [btrfs]
2011-08-29T02:00:46.562966+01:00 picard kernel: [ 4155.444773]
[a0317862] ? btrfs_lookup_dentry+0x35b/0x392 [btrfs]
2011-08-29T02:00:46.562969+01:00 picard kernel: [ 4155.444790]
[a03178a2] ? btrfs_lookup+0x9/0x1f [btrfs]
2011-08-29T02:00:46.562971+01:00 picard kernel: [ 4155.444801]
[810ccf63] ? d_alloc_and_lookup+0x3a/0x60
2011-08-29T02:00:46.562973+01:00 picard kernel: [ 4155.444810]
[810ce356] ? walk_component+0x210/0x3b7
2011-08-29T02:00:46.562975+01:00 picard kernel: [ 4155.444818]
[810cea4a] ? path_lookupat+0x7c/0x29e
2011-08-29T02:00:46.562979+01:00 picard kernel: [ 4155.444827]
[810cfc34] ? do_path_lookup+0x1c/0x87
2011-08-29T02:00:46.562981+01:00 picard kernel: [ 4155.444835]
[810cffe2] ? user_path_at+0x49/0x7b
2011-08-29T02:00:46.562983+01:00 picard kernel: [ 4155.444843]
[810c8781] ? vfs_fstatat+0x3c/0x6a
2011-08-29T02:00:46.562986+01:00 picard kernel: [ 4155.444853]
[8102d38e] ? sub_preempt_count+0x83/0x94
2011-08-29T02:00:46.562988+01:00
Re: kernel BUG at fs/btrfs/inode.c:2299
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote: On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote: I receive the bug when I try to snapshot from fcron: 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76] [ cut here ] 2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kernel BUG at fs/btrfs/inode.c:2299! 2011-08-29T02:00:46.529256+01:00 picard kernel: [ 4155.98] invalid opcode: [#1] PREEMPT SMP 2011-08-29T02:00:46.529259+01:00 picard kernel: [ 4155.444506] CPU 1 2011-08-29T02:00:46.529264+01:00 picard kernel: [ 4155.444508] Modules linked in: microcode reiserfs btrfs zlib_deflate libcrc32c arc4 snd_hda_codec_conexant iwlagn mac80211 uvcvideo videodev v4l2_compat_ioctl32 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd thinkpad_acpi soundcore snd_page_alloc hwmon rfkill nvram e1000e zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm configs ipv6 autofs4 usbhid uhci_hcd firewire_ohci firewire_core sdhci_pci ehci_hcd crc_itu_t sdhci mmc_core sd_mod usbcore sr_mod cdrom 2011-08-29T02:00:46.529267+01:00 picard kernel: [ 4155.444569] 2011-08-29T02:00:46.529270+01:00 picard kernel: [ 4155.444576] Pid: 3167, comm: btrfs Tainted: P C 3.0.3-gentoo #1 LENOVO 2242CTO/2242CTO 2011-08-29T02:00:46.529274+01:00 picard kernel: [ 4155.444586] RIP: 0010:[a031339b] [a031339b] btrfs_orphan_del +0x8d/0xa9 [btrfs] 2011-08-29T02:00:46.529276+01:00 picard kernel: [ 4155.444611] RSP: :880111c21b58 EFLAGS: 00010282 2011-08-29T02:00:46.529279+01:00 picard kernel: [ 4155.444619] RAX: fffe RBX: 88011141bd60 RCX: 1000 2011-08-29T02:00:46.529289+01:00 picard kernel: [ 4155.444626] RDX: 000f RSI: 880110c8d250 RDI: 880134092d80 2011-08-29T02:00:46.529292+01:00 picard kernel: [ 4155.444634] RBP: R08: 880111c21a30 R09: 0011 2011-08-29T02:00:46.529297+01:00 picard kernel: [ 4155.444642] R10: 01dc R11: 0286 R12: 880136866300 2011-08-29T02:00:46.529299+01:00 picard kernel: [ 4155.444650] R13: 880130cac800 R14: 0001 R15: 880130cacb88 2011-08-29T02:00:46.529302+01:00 picard kernel: [ 4155.444658] FS: 7f126715a740() GS:88013bc8() knlGS: 2011-08-29T02:00:46.529304+01:00 picard kernel: [ 4155.444666] CS: 0010 DS: ES: CR0: 8005003b 2011-08-29T02:00:46.529307+01:00 picard kernel: [ 4155.444673] CR2: 7f5149eb7008 CR3: 9caca000 CR4: 000406e0 2011-08-29T02:00:46.529309+01:00 picard kernel: [ 4155.444681] DR0: DR1: DR2: 2011-08-29T02:00:46.529311+01:00 picard kernel: [ 4155.444689] DR3: DR6: 0ff0 DR7: 0400 2011-08-29T02:00:46.529314+01:00 picard kernel: [ 4155.444697] Process btrfs (pid: 3167, threadinfo 880111c2, task 88010b35a140) 2011-08-29T02:00:46.529316+01:00 picard kernel: [ 4155.444705] Stack: 2011-08-29T02:00:46.529318+01:00 picard kernel: [ 4155.444711] 00c369c5 880130cac800 880110c8dbe0 00c369c5 2011-08-29T02:00:46.529321+01:00 picard kernel: [ 4155.444720] 880130cacb88 880130cacb90 a03173c4 2011-08-29T02:00:46.562822+01:00 picard kernel: [ 4155.444730] 880136866300 88011141bd60 880110c8dbe0 fffb 2011-08-29T02:00:46.562959+01:00 picard kernel: [ 4155.444739] Call Trace: 2011-08-29T02:00:46.562964+01:00 picard kernel: [ 4155.444756] [a03173c4] ? btrfs_orphan_cleanup+0x196/0x2d9 [btrfs] 2011-08-29T02:00:46.562966+01:00 picard kernel: [ 4155.444773] [a0317862] ? btrfs_lookup_dentry+0x35b/0x392 [btrfs] 2011-08-29T02:00:46.562969+01:00 picard kernel: [ 4155.444790] [a03178a2] ? btrfs_lookup+0x9/0x1f [btrfs] 2011-08-29T02:00:46.562971+01:00 picard kernel: [ 4155.444801] [810ccf63] ? d_alloc_and_lookup+0x3a/0x60 2011-08-29T02:00:46.562973+01:00 picard kernel: [ 4155.444810] [810ce356] ? walk_component+0x210/0x3b7 2011-08-29T02:00:46.562975+01:00 picard kernel: [ 4155.444818] [810cea4a] ? path_lookupat+0x7c/0x29e 2011-08-29T02:00:46.562979+01:00 picard kernel: [ 4155.444827] [810cfc34] ? do_path_lookup+0x1c/0x87 2011-08-29T02:00:46.562981+01:00 picard kernel: [ 4155.444835] [810cffe2] ? user_path_at+0x49/0x7b 2011-08-29T02:00:46.562983+01:00 picard kernel: [ 4155.444843] [810c8781] ? vfs_fstatat+0x3c/0x6a 2011-08-29T02:00:46.562986+01:00 picard kernel: [ 4155.444853] [8102d38e] ? sub_preempt_count+0x83/0x94 2011-08-29T02:00:46.562988+01:00 picard kernel: [ 4155.444861] [810c88ab] ? sys_newstat+0x12/0x2b 2011-08-29T02:00:46.562990+01:00 picard kernel: [ 4155.444870
kernel BUG at fs/btrfs/inode.c:2299
I receive the bug when I try to snapshot from fcron: 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76] [ cut here ] 2011-08-29T02:00:46.529253+01:00 picard kernel: [ 4155.90] kernel BUG at fs/btrfs/inode.c:2299! 2011-08-29T02:00:46.529256+01:00 picard kernel: [ 4155.98] invalid opcode: [#1] PREEMPT SMP 2011-08-29T02:00:46.529259+01:00 picard kernel: [ 4155.444506] CPU 1 2011-08-29T02:00:46.529264+01:00 picard kernel: [ 4155.444508] Modules linked in: microcode reiserfs btrfs zlib_deflate libcrc32c arc4 snd_hda_codec_conexant iwlagn mac80211 uvcvideo videodev v4l2_compat_ioctl32 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd thinkpad_acpi soundcore snd_page_alloc hwmon rfkill nvram e1000e zram(C) rtc_cmos tp_smapi thinkpad_ec psmouse fscache kvm_intel kvm configs ipv6 autofs4 usbhid uhci_hcd firewire_ohci firewire_core sdhci_pci ehci_hcd crc_itu_t sdhci mmc_core sd_mod usbcore sr_mod cdrom 2011-08-29T02:00:46.529267+01:00 picard kernel: [ 4155.444569] 2011-08-29T02:00:46.529270+01:00 picard kernel: [ 4155.444576] Pid: 3167, comm: btrfs Tainted: P C 3.0.3-gentoo #1 LENOVO 2242CTO/2242CTO 2011-08-29T02:00:46.529274+01:00 picard kernel: [ 4155.444586] RIP: 0010:[a031339b] [a031339b] btrfs_orphan_del +0x8d/0xa9 [btrfs] 2011-08-29T02:00:46.529276+01:00 picard kernel: [ 4155.444611] RSP: :880111c21b58 EFLAGS: 00010282 2011-08-29T02:00:46.529279+01:00 picard kernel: [ 4155.444619] RAX: fffe RBX: 88011141bd60 RCX: 1000 2011-08-29T02:00:46.529289+01:00 picard kernel: [ 4155.444626] RDX: 000f RSI: 880110c8d250 RDI: 880134092d80 2011-08-29T02:00:46.529292+01:00 picard kernel: [ 4155.444634] RBP: R08: 880111c21a30 R09: 0011 2011-08-29T02:00:46.529297+01:00 picard kernel: [ 4155.444642] R10: 01dc R11: 0286 R12: 880136866300 2011-08-29T02:00:46.529299+01:00 picard kernel: [ 4155.444650] R13: 880130cac800 R14: 0001 R15: 880130cacb88 2011-08-29T02:00:46.529302+01:00 picard kernel: [ 4155.444658] FS: 7f126715a740() GS:88013bc8() knlGS: 2011-08-29T02:00:46.529304+01:00 picard kernel: [ 4155.444666] CS: 0010 DS: ES: CR0: 8005003b 2011-08-29T02:00:46.529307+01:00 picard kernel: [ 4155.444673] CR2: 7f5149eb7008 CR3: 9caca000 CR4: 000406e0 2011-08-29T02:00:46.529309+01:00 picard kernel: [ 4155.444681] DR0: DR1: DR2: 2011-08-29T02:00:46.529311+01:00 picard kernel: [ 4155.444689] DR3: DR6: 0ff0 DR7: 0400 2011-08-29T02:00:46.529314+01:00 picard kernel: [ 4155.444697] Process btrfs (pid: 3167, threadinfo 880111c2, task 88010b35a140) 2011-08-29T02:00:46.529316+01:00 picard kernel: [ 4155.444705] Stack: 2011-08-29T02:00:46.529318+01:00 picard kernel: [ 4155.444711] 00c369c5 880130cac800 880110c8dbe0 00c369c5 2011-08-29T02:00:46.529321+01:00 picard kernel: [ 4155.444720] 880130cacb88 880130cacb90 a03173c4 2011-08-29T02:00:46.562822+01:00 picard kernel: [ 4155.444730] 880136866300 88011141bd60 880110c8dbe0 fffb 2011-08-29T02:00:46.562959+01:00 picard kernel: [ 4155.444739] Call Trace: 2011-08-29T02:00:46.562964+01:00 picard kernel: [ 4155.444756] [a03173c4] ? btrfs_orphan_cleanup+0x196/0x2d9 [btrfs] 2011-08-29T02:00:46.562966+01:00 picard kernel: [ 4155.444773] [a0317862] ? btrfs_lookup_dentry+0x35b/0x392 [btrfs] 2011-08-29T02:00:46.562969+01:00 picard kernel: [ 4155.444790] [a03178a2] ? btrfs_lookup+0x9/0x1f [btrfs] 2011-08-29T02:00:46.562971+01:00 picard kernel: [ 4155.444801] [810ccf63] ? d_alloc_and_lookup+0x3a/0x60 2011-08-29T02:00:46.562973+01:00 picard kernel: [ 4155.444810] [810ce356] ? walk_component+0x210/0x3b7 2011-08-29T02:00:46.562975+01:00 picard kernel: [ 4155.444818] [810cea4a] ? path_lookupat+0x7c/0x29e 2011-08-29T02:00:46.562979+01:00 picard kernel: [ 4155.444827] [810cfc34] ? do_path_lookup+0x1c/0x87 2011-08-29T02:00:46.562981+01:00 picard kernel: [ 4155.444835] [810cffe2] ? user_path_at+0x49/0x7b 2011-08-29T02:00:46.562983+01:00 picard kernel: [ 4155.444843] [810c8781] ? vfs_fstatat+0x3c/0x6a 2011-08-29T02:00:46.562986+01:00 picard kernel: [ 4155.444853] [8102d38e] ? sub_preempt_count+0x83/0x94 2011-08-29T02:00:46.562988+01:00 picard kernel: [ 4155.444861] [810c88ab] ? sys_newstat+0x12/0x2b 2011-08-29T02:00:46.562990+01:00 picard kernel: [ 4155.444870] [81346d4f] ? page_fault+0x1f/0x30 2011-08-29T02:00:46.562992+01:00 picard kernel: [ 4155.444878] [8134713b] ? system_call_fastpath+0x16/0x1b 2011-08-29T02:00:46.562995+01:00 picard kernel: [ 4155.444885] Code: 4d 85 e4 74 28 48 8b 93 70 fe ff ff 48 81 fa 00 01 00 00 77 07 48
Re: BTRFS and power loss ~= corruption?
On Thu, 2011-08-25 at 19:55 +0200, Martin Steigerwald wrote: That said I also do not have any issues with BTRFS on a ThinkPad T23 for / and /home. But then the machine has an hibernate-to-disk-and-resume uptime of almost 120 days, so it didn´t see a power loss for a long time. Thats still with 2.6.38.4. Which method of hibernation are you using? I got enormous problems with btrfs+toi including: - Freezes resulting in umountable partition (twice so far, 2 results in google including one message I sent to list) - Sometimes a random program (Skype, Firefox) cannot be frozen and stacktracke includes btrfs AIO. regards signature.asc Description: This is a digitally signed message part
BTRFS corruption - the filesystem grows and the new files appears (at least)
Hello, I got btrfs corruption and I'm not sure if it is known yet. i suspect that it happened after hard reset (I got freeze first so I'm not sure if it wasn't caused by something else). The symptoms are that the allocation grows at all time during read/writes (it reached 49 GB for 30 GB of data on disk in total). Btrfsck reported several errors (and wasted space) but the partition mounted nonetheless. I created the disk image and copy the data from image to the partition. I haven't compared the checksums of files but I haven't found any other then 1 new file with random (i.e. the nautilus complained that the name is not valid) name. Is is known error or should I include the debug data (the btrfsck output etc.)? My kernel is 3.0.3. Regards signature.asc Description: This is a digitally signed message part
Re: BTRFS corruption - the filesystem grows and the new files appears (at least)
On Mon, 2011-08-22 at 14:06 +0100, Maciej Marcin Piechotka wrote: Hello, I got btrfs corruption and I'm not sure if it is known yet. i suspect that it happened after hard reset (I got freeze first so I'm not sure if it wasn't caused by something else). The symptoms are that the allocation grows at all time during read/writes (it reached 49 GB for 30 GB of data on disk in total). Btrfsck reported several errors (and wasted space) but the partition mounted nonetheless. I created the disk image and copy the data from image to the partition. I haven't compared the checksums of files but I haven't found any other then 1 new file with random (i.e. the nautilus complained that the name is not valid) name. Is is known error or should I include the debug data (the btrfsck output etc.)? My kernel is 3.0.3. Regards 1. This is a data corruption. I got ~20 files corrupted (at least) 2. The output of btrfsck (I reproduced it twice - each time it was on new partition with rsync from mounted image): # btrfsck /media/BACKUP/home.4.img Device 1 (/media/BACKUP/home.4.img) opened in fd 4 couldn't open because of unsupported option features (8). root 5 inode 18446744073709551604 errors 2000 root 5 inode 18446744073709551605 errors 1 root 256 inode 286682 errors 400 root 256 inode 286901 errors 400 root 256 inode 286915 errors 400 root 256 inode 286918 errors 400 root 256 inode 286934 errors 400 root 256 inode 18446744073709551604 errors 2000 root 256 inode 18446744073709551605 errors 1 found 41491558400 bytes used err is 1 total csum bytes: 40017208 total tree bytes: 512430080 total fs tree bytes: 429453312 btree space waste bytes: 132018866 file data blocks allocated: 41102532608 referenced 42599010304 Btrfs v0.19-36-ge36502e-dirty # btrfsck /media/BACKUP/home.5.img Device 1 (/media/BACKUP/home.5.img) opened in fd 4 couldn't open because of unsupported option features (8). root 5 inode 18446744073709551604 errors 2000 root 5 inode 18446744073709551605 errors 1 root 257 inode 1911 errors 400 root 257 inode 6629 errors 400 root 257 inode 190598 errors 400 root 257 inode 194632 errors 400 root 257 inode 199345 errors 400 root 257 inode 199613 errors 400 root 257 inode 201378 errors 400 root 257 inode 18446744073709551604 errors 2000 root 257 inode 18446744073709551605 errors 1 root 259 inode 18446744073709551604 errors 2000 root 259 inode 18446744073709551605 errors 1 found 33812979712 bytes used err is 1 total csum bytes: 32674804 total tree bytes: 351416320 total fs tree bytes: 280096768 btree space waste bytes: 76978911 file data blocks allocated: 33551613952 referenced 38453358592 Btrfs v0.19-36-ge36502e-dirty 3. I believe that it happens on 3.0.3 but I didn't had it on 3.0.1. Each time the screen went blank and computer freezed. The second time I got the well-known kernel OOPS bug. Regards signature.asc Description: This is a digitally signed message part
Re: Honest timeline for btrfsck
On Thu, 2011-08-18 at 16:50 -0400, Chris Mason wrote: Excerpts from Yalonda Gishtaka's message of 2011-08-17 21:09:37 -0400: Chris Mason chris.mason at oracle.com writes: Aside from making sure the kernel code is stable, btrfsck is all I'm working on right now. I do expect a release in the next two weeks that can recover your data (and many others). Thanks, Chris -- Chris, We're all on the edge of our seats. Can you provide an updated ETA on the release of the first functional btrfsck tool? No pressure or anything ;) Hi everyone, I've been working non-stop on this. Currently fsck has four parts: 1) mount -o recovery mode. I've posted smaller forms of these patches in the past that bypass log tree replay. The new versions have code to create stub roots for trees that can't be read (like the extent allocation tree) and will allow the mount to proceed. 2) fsck that scans for older roots. This takes advantage of older copies of metadata to look for consistent tree roots on disk. The downside is that it is currently very slow. I'm trying to speed it up by limiting the search to only the metadata block groups and a few other tricks. 3) fsck that fixes the extent allocation tree and the chunk tree. This is where I've been spending most of my time. The problem is that it tends to recover some filesystems and badly break others. While I'm fixing up the corner cases that work poorly, I'm adding an undo log to the fsck code so that you can get the FS back into its original state if you don't like the result of the fsck. 4) The rest of the corruptions can be dealt with fairly well from the kernel. I have a series of patches to make the extent allocation tree less strict about reference counts and other rules, basically allowing the FS to limp along instead of crash. These four things together are basically my minimal set of features required for fedora and our own internal projects at Oracle to start treating us as production filesystem. There are always bugs to fix, and I have #1 and #2 mostly ready. I had hoped to get #1 out the door before I left on vacation and I still might post it tonight. Greate to hear that. Given that I get corruption every 2 week I would like to at least test the tools - are there available anywhere? I'd like to see #2 (it seems to be able to fix my main crashes). Best regards signature.asc Description: This is a digitally signed message part
