Re: [opensuse-factory] Should I switch to Btrfs?
I've had quite a look at btrfs on my machines and I'll some up my results in a (very brief) Pro's/Con's list Pros- Faster in certain circumstances Snapshots and snapper is awesome "It's the future" Cons- Slower in certain circumstances (like every benchmark and every 'real world' test I've tried. Slower boot times, etc) SSD performance seems to be variable depending on your SSD and how you tweak btrfs no fsck / only just introduced - It doesn't 'feel' ready yet I totally understand anyone who goes for btrfs, those pros are pretty nice and shiny new stuff is always fun but for now I've decided to stick with ext4, it's stable, it faster than muck through a goose, and it does everything I need it to do, if not everything I want.
Jos Poortvliet 11/14/11 1:30 PM >>> On Wednesday, November 09, 2011 13:38:55 Roger Luedecke wrote: I'm thinking of switching to Btrfs. Benchmarks show significant improvement in random write speed. It seems to me that would be a boon to Akonadi which the new Kmail that I adore is based on. I am not concerned too much with losing data from a filesystem problem that would need fsck.What do you think?
Please feel free to pipe up on any issue I may be unaware of. I am thinking of this for the fresh install of 12.1 on my HPMini 311-1000nr netbook. It has a 149.1G IDE, Intel Atom CPU N270 @1.6Ghz with virtual dual core, and 2.07G of RAM.
I;'m having btrfs and frankly it's a pain on this SSD. Might be different on a hard drive, but be sure not to come even close to running out of space as btrfs does NOT handle that very well (gets extremely slow). In general I'm not happy with my choice, even the latest kernel in 12.1 does little to alleviate the pain. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown wrote:
Cons- no fsck /
--- I'd regard that in the 'Pros' category... XFS doesn't need fsck on / or any other file system. (I just manually have to remember to change it to a link to '/bin/true', or similar, after an upgrade...)... Only thing it does is detect if a fs is present. I didn't realize it, but I had removed a file system in order to re-allocate space in the volume -- well -- never got around to recreating it, as it wasn't needed at this point (not mounting snapshots, so no need for a separate dev to hold a snapshot dir)... It WAS set in fstab as '3 0' (last to be mounted), another used to create backups was also removed, but it was in fstab as '0 0' so wouldn't have affected the boot process anyway. But the point I've made before on this -- is that the snapshot dir missing wasn't something that I would have wanted to prevent boot. Yet if I ran with the standard fsck (apparently xfs-team changed it to be posix compliant and it should return error if a listed fs doesn't mount -- and therefore prevent boot so you can't investigate what happened).... Understanding how that behavior might be desired for some -- I've never seen an environment where having the system drop into single user and not be network reachable was a good way to handle failure. Perhaps if it came up to level 2 and enabled root login only...that would be fine...but in this day when people manage systems remotely -- having the system come up in ANY shape so I can connect via network, is FAR preferable, to "refused to boot on any missing disk".... though if there is a problem, I wouldn't have issue in restricting login to 1 user at a time (even if remote)....(probably can't restrict to root, as many sites require remote login with a user id/restrict remotely root direct login.... FSCK made sense to not use file systems that by using them, could cause further corruption. But it doesn't make sense for fsck to return an error on a non-existent disk, as it's a *file system checker*, NOT a 'device presence detector' (despite that such a function has been overloaded upon the original design). If there is no FS to chck, then it isn't possible to return status. It should should exit with a 'not_run' status... Services that "don't run", don't automatically throw you into single user. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (2)
-
Linda Walsh
-
Richard Brown