Originally posted by zanny
View Post
Announcement
Collapse
No announcement yet.
openSUSE 13.2 To Use Btrfs By Default, Major Changes
Collapse
X
-
-
-
Originally posted by zanny View PostI'm still wondering where my fsck.btrfs is. I use it on all my machines, but whenever something *does* go wrong, like corrupted extents, I have to boot to a usb drive to run btrfsck on my root partition. And even then, btrfsck is like a meat cleaver to fix problems (especially in repair mode) when you really just want a steak knife to prune the damage.
You could mount the partition with the recover mount parameter, but that is not recomended unless you are instructed to do so.
I'm surprised they declared butterfs stable so fast. Good for them.
Comment
-
From what I know, the intention of a fsck.btrfs is not there because it should not be needed just like defragmentation.
Of course, background defragmenting beats the crap out of the mess of running a defragmenter on Windows and crippling the machine until it finishes.
Also, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.
Comment
-
Originally posted by zanny View Postbtrfs would be a bad example of "not needing defragmentation" because btrfs volumes do see file fragmentation due to the way CoW works. There is even a mount option of autodefrag to have background processes fixing the most fragmented files.
Originally posted by zanny View PostOf course, background defragmenting beats the crap out of the mess of running a defragmenter on Windows and crippling the machine until it finishes.
Originally posted by zanny View PostAlso, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.
Comment
-
Originally posted by zanny View PostAlso, on the topic of mounting in recovery - I've had btrfs extent table corruption to the point where the kernel panicked if it tried to mount that volume. At that point you really need that usb repair drive. Also, in my setup, since I boot from EFIstub, I'm unable to change the kernel parameters in early boot and I can't use a recovery initrd with btrfs on it.
Comment
-
ZFS is production for large data, use ECC RAM. Btrfs welcome.
BTRFS is all great for Linux (had it been ported anywhere else?) , and I would definitevely use it for Linux installs for Workstations and some servers.
But, isnt ZFS in productioin for, say at least 8 years now and counting?
I got used to not to worry about FSCK on boot, because it does not exist on ZFS and that could be decesieve factor when you have large number of disks and do not want to wait for eons for server to boot.
And oh, yes, OpenZFS is supported in Linux with ZFSOnLinux kernel module (booting from ZFS), ZFS on FUSE, FreeBSD's default, Solaris (up to v28) and illumos distros (Openindiana, SmartOS etc) and OSX with 2+ implementations (think that Windows is on the way).
At the present time I would definatevly give thumbs up to Btrfs on Linux for Boot from it and finally, after 8+ years catching up with Opensolaris file system.
But everyone wanting to be able to count on their (large) data is better off with ZFS data pools in production and multiplatform use.
Seems like expensive RAID controller cards are going to the history and large (ECC!) RAM is "new RAID".Last edited by Markore; 13 April 2014, 04:06 AM.
Comment
Comment