View previous topic :: View next topic |
Author |
Message |
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Oct 10, 2011 5:43 pm Post subject: |
|
|
Btrfs ate my netbook today. Unexpected power loss, when it came back it panicked on boot mounting the filesystem. Impossible to get a backtrace since most of it flies off the top of the screen, and AFAIK, btrfsck is a dummy command that doesn't actually fix anything. Back to ext4 for me then.
I guess I deserved the data loss for being naïve enough to use Oracle software in the first place |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Oct 10, 2011 7:45 pm Post subject: |
|
|
pjp wrote: | btrfs remains under heavy development and is not yet intended for use where data loss is a problem or inconvenience. Using it at this point seems to be acceptance of such issues. |
pjp wrote: | Anyway, as for trying ZFS, I've used ~arch way back when ('03 - '04) and had problems. I've decided to never do that again, so I only use stable. I'm also not interested in maintaining random overlays separately from portage (I find it to be a nuisance), and even less interested in maintaining custom ebuilds, especially of the critical variety. None of those scenarios are why I started using Gentoo, or continue using it. |
Those two statements are contradictory. BTRFS is unstable at this time with no way to recover but you advocate it. ZFS is super stable but you don't want to use it just because its not in portage. Tells me you have a mental bias! But, to each their own! |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Mon Oct 10, 2011 10:32 pm Post subject: |
|
|
I have not advocated for anyone to use btrfs.
As for what I have done, I've considered testing btrfs with data I don't care if I lose. I have installed btrfs in a virtual box, just to see how to interact with it (ZFS' cli is better IMO). In doing so, btrfs seems easier to implement currently than ZFS (without supported ebuilds, and purely from a package management point of view). If a supported ZFS ebuild comes along, I'd try it in a vm as well.
I'm glad you like ZFS. It seems appropriate for your situation and your tolerance for data loss. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Oct 15, 2011 5:35 pm Post subject: |
|
|
I just found this on the Arch wiki, which let me salvage my SSD data. |
|
Back to top |
|
|
lkraav Tux's lil' helper
Joined: 13 Oct 2004 Posts: 129 Location: Estonia
|
Posted: Sat Oct 15, 2011 5:41 pm Post subject: |
|
|
i just had a situation where a btrfs partition wouldnt mount. solution is to mount the partition with 2.6.38 kernel one time, for example systemrescuecd 2.1.1, so it could repair the log. waiting for pf-sources-3.1 .. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Oct 22, 2011 3:40 pm Post subject: |
|
|
There's nothing wrong with throwing away corrupt incomplete data after a crash, xfs does it by default and you just lose the last 15 seconds of data or so. The main difference is that does it automatically, instead of kernel panicking, forcing you hunt across google for an hour and then manually compile a non-default tool from a livecd to fix it... |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Sat Oct 22, 2011 5:20 pm Post subject: |
|
|
Ant P. wrote: | There's nothing wrong with throwing away corrupt incomplete data after a crash, xfs does it by default and you just lose the last 15 seconds of data or so. | That's just plain wrong! Is that your definition of enterprise-ready filesystem? Do you have any idea how many transactions can be processed in 15 seconds? |
|
Back to top |
|
|
Simba7 l33t
Joined: 22 Jan 2007 Posts: 706 Location: Billings, MT, USA
|
Posted: Sun Oct 23, 2011 4:42 pm Post subject: |
|
|
Ant P. wrote: | There's nothing wrong with throwing away corrupt incomplete data after a crash, xfs does it by default and you just lose the last 15 seconds of data or so. The main difference is that does it automatically, instead of kernel panicking, forcing you hunt across google for an hour and then manually compile a non-default tool from a livecd to fix it... |
Let me make sure I *NEVER* hire you as a network or system administrator. Fifteen seconds of data can equal several tens of gigabytes in an enterprise environment. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Mon Oct 24, 2011 2:24 pm Post subject: |
|
|
devsk wrote: | That's just plain wrong! Is that your definition of enterprise-ready filesystem? |
No, that's SGI's definition of an enterprise-ready filesystem. This has been its default behaviour for years. If you don't like it then RTFM and learn how to change the default.
devsk wrote: | Do you have any idea how many transactions can be processed in 15 seconds? |
Simba7 wrote: | Let me make sure I *NEVER* hire you as a network or system administrator. |
If you're even thinking of running mission-critical systems that can't tolerate 15 seconds of downtime on a standard Linux filesystem without redundancy and expecting not to lose data then I want to stay as far away from whatever company you work for as possible |
|
Back to top |
|
|
devsk Advocate
Joined: 24 Oct 2003 Posts: 2995 Location: Bay Area, CA
|
Posted: Mon Oct 24, 2011 2:47 pm Post subject: |
|
|
Ant P. wrote: | devsk wrote: | That's just plain wrong! Is that your definition of enterprise-ready filesystem? |
No, that's SGI's definition of an enterprise-ready filesystem. This has been its default behaviour for years. If you don't like it then RTFM and learn how to change the default. | And that's exactly why it has such deep penetration in the enterprise world... |
|
Back to top |
|
|
ToeiRei Veteran
Joined: 03 Jan 2005 Posts: 1191 Location: Austria
|
Posted: Wed Nov 02, 2011 11:25 am Post subject: |
|
|
btrfs-progs know about scrubbing now. Just too bad you don't get the filename/path of the corrupted files yet... But that's about to come in Kernel 3.2 (patches queued up already, testing them now)
if you feel like you want to test stuff, here's what I did to patch:
Code: |
cd /usr/src/linux
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=5da6fcbc4eb50c0f55d520750332f5a6ab13508c" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=4a54c8c165b66300830a67349fc7595e3fc442f7" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=2774b2ca3d49124bf1ae89e8d575b3dab4221266" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=1503140d3ec2be9b917d2f8f7c64cb77b79a215b" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=a1d3c4786a4b9c71c0767aa656a759968f7554b6" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=d7728c960dccf775b92f2c4139f1216275a45c44" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=0ef8e45158f97dde4801b535e25f70f7caf01a27" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=e12fa9cd390f8e93a9144bd99bd6f6ed316fbc1e" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=8ddc7d9cd0a00062247c732b96386ec2462bdbc7" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=193ea74b2729e6ddc08fb6bde6e15a3bd4d94071" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=558540c17771eaf89b1a3be39aa2c8bc837da1a6" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=13db62b7a1e8c64763a93c155091620f85ff8920" | patch -p1
curl -s "http://git.jan-o-sch.net/?p=btrfs-unstable;a=patch;h=a542ad1bafc7df9fc16de8a6894b350a4df75572" | patch -p1
|
Compile, reboot and test _________________ Please stand by - The mailer daemon is busy burning your messages in hell... |
|
Back to top |
|
|
Simba7 l33t
Joined: 22 Jan 2007 Posts: 706 Location: Billings, MT, USA
|
Posted: Sat Nov 05, 2011 11:02 pm Post subject: |
|
|
So.. Does btrfs now use a flat 2GB for metadata use?
Also, is there going to be a sparc64 edition? I picked up (5) SunFire V100's (1GB RAM/80GB HDD) that I wouldn't mind throwing Gentoo on. |
|
Back to top |
|
|
hasufell Retired Dev
Joined: 29 Oct 2011 Posts: 429
|
Posted: Sun Nov 06, 2011 9:30 pm Post subject: |
|
|
Ant P. wrote: | Btrfs ate my netbook today. Unexpected power loss, when it came back it panicked on boot mounting the filesystem. Impossible to get a backtrace since most of it flies off the top of the screen, and AFAIK, btrfsck is a dummy command that doesn't actually fix anything. Back to ext4 for me then.
I guess I deserved the data loss for being naïve enough to use Oracle software in the first place |
got the same and solved it by clearing the journal
http://www.funtoo.org/wiki/BTRFS_Fun#In_last_resort:_clearing_the_BTRFS_journal |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
tclover Guru
Joined: 10 Apr 2011 Posts: 516
|
Posted: Wed Nov 09, 2011 1:43 pm Post subject: Impressive? |
|
|
Yeah, that huge commit seems promising for many fixes... although his last comment on btrfs "eating his data" with no possibility/time for fixes before pulling his request is not that appealing. I'd look at you guys--who are using btrfs--with a little distance with your "eaten data" funny stories before making any move to btrfs.
But hey, again, that pull request is impressive! and it's normally trouble free on top of 3.1. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
Posted: Wed Nov 09, 2011 3:25 pm Post subject: |
|
|
still not ready for production / normal backup purpose:
Quote: | [ 8189.430062] ------------[ cut here ]------------
[ 8189.430103] Kernel BUG at ffffffff812beaa7 [verbose debug info unavailable]
[ 8189.430151] invalid opcode: 0000 [#1] PREEMPT SMP
[ 8189.430204] CPU 4
[ 8189.430221] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect iptable_filter ip_tables x_tables it87 hwmon_vid coretemp snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore e1000e i7core_edac wmi i2c_i801 snd_page_alloc libphy e1000 auth_rpcgss lockd sunrpc scsi_wait_scan sl811_hcd ohci_hcd ssb usb_storage ehci_hcd [last unloaded: nfs_acl]
[ 8189.430752]
[ 8189.430766] Pid: 10477, comm: btrfs-transacti Not tainted 3.1.0-btrfs++ #1 Packard Bell ipower G3710/FMP55
[ 8189.430841] RIP: 0010:[<ffffffff812beaa7>] [<ffffffff812beaa7>] btrfs_delalloc_release_metadata+0xf7/0x100
[ 8189.430914] RSP: 0018:ffff8801c8c99c70 EFLAGS: 00010246
[ 8189.430952] RAX: 0000000000000000 RBX: ffff880232981000 RCX: 0000000000f70a14
[ 8189.431002] RDX: 0000000000f70a04 RSI: 0000000000009000 RDI: ffff88016fd9c42c
[ 8189.431051] RBP: ffff88016fd9c42c R08: ffffffff812d5ae3 R09: ffff8801c8c99b00
[ 8189.431101] R10: 0000000000000009 R11: 0000000000000008 R12: 0000000000009000
[ 8189.431150] R13: ffff88016fd9c5a0 R14: 0000000000001000 R15: ffff8801dd43ca20
[ 8189.431200] FS: 0000000000000000(0000) GS:ffff88023fd00000(0000) knlGS:0000000000000000
[ 8189.431256] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 8189.431296] CR2: 0000257b1355b000 CR3: 0000000001c35000 CR4: 00000000000006e0
[ 8189.431345] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8189.431394] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 8189.431444] Process btrfs-transacti (pid: 10477, threadinfo ffff8801c8c98000, task ffff880232735cc0)
[ 8189.431506] Stack:
[ 8189.431521] ffff880232981000 ffff88016fd9c5a0 ffff88015a654500 ffff8801dd723ca8
[ 8189.431583] 00000000ffffffff ffffffff81306924 0000000000000000 0000000000009000
[ 8189.431644] ffff88016fd9c5a0 ffff880232981000 ffff8801dd723ca8 ffff88016fd9c5a0
[ 8189.431705] Call Trace:
[ 8189.431727] [<ffffffff81306924>] ? btrfs_write_out_ino_cache+0xc4/0xd0
[ 8189.431790] [<ffffffff812c7a1e>] ? btrfs_save_ino_cache+0x17e/0x280
[ 8189.431817] [<ffffffff812cf4b8>] ? commit_fs_roots.isra.26+0xb8/0x170
[ 8189.431865] [<ffffffff813179b0>] ? btrfs_scrub_pause+0xf0/0x100
[ 8189.431907] [<ffffffff812d0230>] ? btrfs_commit_transaction+0x3c0/0x7c0
[ 8189.431948] [<ffffffff81068860>] ? add_wait_queue+0x60/0x60
[ 8189.431985] [<ffffffff812d0a39>] ? start_transaction+0x89/0x290
[ 8189.432058] [<ffffffff812c91cd>] ? transaction_kthread+0x24d/0x260
[ 8189.432097] [<ffffffff812c8f80>] ? btrfs_congested_fn+0xc0/0xc0
[ 8189.432137] [<ffffffff8106810e>] ? kthread+0x7e/0x90
[ 8189.432167] [<ffffffff8169f874>] ? kernel_thread_helper+0x4/0x10
[ 8189.432201] [<ffffffff81068090>] ? kthread_worker_fn+0x180/0x180
[ 8189.432237] [<ffffffff8169f870>] ? gs_change+0xb/0xb
[ 8189.432263] Code: 00 00 4c 8b 74 24 20 48 83 c4 28 e9 84 fb ff ff 0f 1f 40 00 4c 89 ef 31 d2 e8 06 85 ff ff 48 89 ef 49 89 c5 e8 2b ec 3d 00 eb b0 <0f> 0b 0f 1f 80 00 00 00 00 48 83 ec 28 48 89 5c 24 18 48 89 fb
[ 8189.432540] RIP [<ffffffff812beaa7>] btrfs_delalloc_release_metadata+0xf7/0x100
[ 8189.432581] RSP <ffff8801c8c99c70>
[ 8189.450827] ---[ end trace 1b95a00d25cebed8 ]---
|
afaik this happens with inode_cache enabled pretty reliably
[3.0+]
no time for a in-depth bug report *sigh*
will try again & see if this also happens with the inode cache disabled ...
edit:
ok, not inode_cache related - but inode_cache seems to speed up transfers up significantly
still happening
looks like a regression or BUG introduced by 3.0 kernel series
back to ZFS for now until someone else who has time stumbles over this issues reproducibly & can go through it with the devs and test fixes :\ _________________ https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004 |
|
Back to top |
|
|
hasufell Retired Dev
Joined: 29 Oct 2011 Posts: 429
|
Posted: Tue Dec 06, 2011 3:21 pm Post subject: |
|
|
after about 3 months of using btrfs on rootfs i gave up and switched back to ext4.
The systems is often unresponive and I even got serious slowdowns (cant really move mousepointer) when doing "emerge --sync", not to mention rsync...
Sometimes there are very long write-operations and I can't even tell why.
with ext4... all that stuff is gone, so it's definitely not just imagination. |
|
Back to top |
|
|
Dont Panic Guru
Joined: 20 Jun 2007 Posts: 322 Location: SouthEast U.S.A.
|
Posted: Tue Dec 06, 2011 5:08 pm Post subject: |
|
|
I've seen several posts on the Btrfs Mailing List regarding slowdowns.
I've never experienced it myself.
But they've been having a hard time nailing that issue down since it's hard to replicate. And it seems like every time they think they have it fixed, it crops back up again in a month or two. |
|
Back to top |
|
|
hasufell Retired Dev
Joined: 29 Oct 2011 Posts: 429
|
Posted: Wed Dec 07, 2011 7:32 pm Post subject: |
|
|
maybe it performs differently on storage partitions |
|
Back to top |
|
|
Small_Penguin Tux's lil' helper
Joined: 27 May 2005 Posts: 140
|
Posted: Tue Dec 20, 2011 11:20 pm Post subject: |
|
|
I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!
However, using ext4 with 1024 block size: /dev/sdb5 519412 376850 142562 73% /usr/portage
It's a pity ext4 can't do compression. However, both its stability and configurability are great and I had no problems so far. |
|
Back to top |
|
|
darklegion Guru
Joined: 14 Nov 2004 Posts: 468
|
Posted: Sun Jan 01, 2012 12:40 am Post subject: |
|
|
Small_Penguin wrote: | I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!
However, using ext4 with 1024 block size: /dev/sdb5 519412 376850 142562 73% /usr/portage
It's a pity ext4 can't do compression. However, both its stability and configurability are great and I had no problems so far. |
You need to enable the "-M" option when creating a small partition with btrfs. Otherwise it will use a lot of space for metadata. Regarding compressing /usr/portage you should probably use something like squashfs. |
|
Back to top |
|
|
upengan78 l33t
Joined: 27 Jun 2007 Posts: 711 Location: IL
|
Posted: Thu Jan 19, 2012 8:36 pm Post subject: |
|
|
darklegion wrote: | Small_Penguin wrote: | I wanted to try btrfs with lzo compression for /usr/portage, hoping for the compression to speed things up.
Its partition size is only 512MiB. Unfortunately, the data does not even fit with btrfs. What a showstopper!
However, using ext4 with 1024 block size: /dev/sdb5 519412 376850 142562 73% /usr/portage
It's a pity ext4 can't do compression. However, both its stability and configurability are great and I had no problems so far. |
You need to enable the "-M" option when creating a small partition with btrfs. Otherwise it will use a lot of space for metadata. Regarding compressing /usr/portage you should probably use something like squashfs. |
mkbtrfs
Code: | usage: mkfs.btrfs [options] dev [ dev ... ]
options:
-A --alloc-start the offset to start the FS
-b --byte-count total number of bytes in the FS
-d --data data profile, raid0, raid1, raid10 or single
-l --leafsize size of btree leaves
-L --label set a label
-m --metadata metadata profile, values like data profile
-n --nodesize size of btree nodes
-s --sectorsize min block allocation
Btrfs Btrfs v0.19 |
Don't see -M here. Can you tell me where one needs to enable -M option ? Thanks. |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
upengan78 l33t
Joined: 27 Jun 2007 Posts: 711 Location: IL
|
Posted: Fri Jan 20, 2012 6:54 pm Post subject: |
|
|
kernelOfTruth wrote: | it should be
mkfs.btrfs -d single -m single /dev/foo
what you're looking for ... |
Thanks for that. I will use it next time when I create btrFS. I already ran mkbtrfs on a device w/o any options yesterday. |
|
Back to top |
|
|
|