On 2018/9/17 下午7:55, Adrian Bastholm wrote: >> Well, I'd say Debian is really not your first choice for btrfs. >> The kernel is really old for btrfs. >> >> My personal recommend is to use rolling release distribution like >> vanilla Archlinux, whose kernel is already 4.18.7 now. > > I just upgraded to Debian Testing which has the 4.18 kernel Then I strongly recommend to use the latest upstream kernel and progs for btrfs. (thus using Debian Testing) And if anything went wrong, please report asap to the mail list. Especially for fs corruption, that's the ghost I'm always chasing for. So if any corruption happens again (although I hope it won't happen), I may have a chance to catch it. > >> Anyway, enjoy your stable fs even it's not btrfs anymore. > > My new stable fs is too rigid. Can't grow it, can't shrink it, can't > remove vdevs from it , so I'm planning a comeback to BTRFS. I guess > after the dust settled I realize I like the flexibility of BTRFS. > > > This time I'm considering BTRFS as rootfs as well, can I do an > in-place conversion ? There's this guide > (https://www.howtoforge.com/how-to-convert-an-ext3-ext4-root-file-system-to-btrfs-on-ubuntu-12.10) > I was planning on following. Btrfs-convert is recommended mostly for short term trial (the ability to rollback to ext* without anything modified) From the code aspect, the biggest difference is the chunk layout. Due to the ext* block group usage, each block group header (except some sparse bg) is always used, thus btrfs can't use them. This leads to highly fragmented chunk layout. We doesn't have error report about such layout yet, but if you want everything to be as stable as possible, I still recommend to use a newly created fs. > > Another thing is I'd like to see a "first steps after getting started > " section in the wiki. Something like take your first snapshot, back > up, how to think when running it - can i just set some cron jobs and > forget about it, or does it need constant attention, and stuff like > that. There are projects do such things automatically, like snapper. If your primary concern is to make the fs as stable as possible, then keep snapshots to a minimal amount, avoid any functionality you won't use, like qgroup, routinely balance, RAID5/6. And keep the necessary btrfs specific operations to minimal, like subvolume/snapshot (and don't keep too many snapshots, say over 20), shrink, send/receive. Thanks, Qu > > BR Adrian > >
Attachment:
signature.asc
Description: OpenPGP digital signature
