On Mon, Jul 15, 2013 at 03:25:29PM +1000, Russell Coker wrote: > They are designed for first-generation filesystems where fsck is a > standard utility that's regularly used as opposed to more modern > filesystems where there is no regularly used fsck because they are > just expected to work all the time.
and as you point out, disks are getting so large that fsck is just impractical. fsck on boot even more so - 10 hours downtime just to reboot? (i particularly hate ext2/3/4's default mount-count and interval settings for auto-fsck on boot...i don't need an fsck just because this is the first time i've rebooted the server in 6 months) > Ext4 and LVM still have their place. ext4, yes - e.g. on laptops and in VM images. not so sure about lvm, there isn't anything it does that zfs and btrfs don't do better. > I'm a little nervous about the extra complexity of ZFS and BTRFS when > combined with a system that lacks ECC RAM. I've already had two BTRFS > problems that required backup/format/restore due to memory errors. i'm far more nervous about undetected errors in current size hard disks using traditional filesystems like ext4 and xfs. RAM is cheap, and the price difference for ECC is not prohibitive. e.g. without spending too much time shopping around for best prices, I found Kingston 8GB DDR3-133 non-ECC being sold pretty much everywhere for around $75. ECC is a bit harder to find but i spotted that megabuy is selling Kingston 8GB DDR3-1333 ECC RAM for $97. http://www.megabuy.com.au/kingston-kvr13e98i-8gb-1333mhz-ddr3-ecc-cl9-dimm-intel-p336271.html they also have DDR3-1600 ECC for the same price. that's about 30% more for ECC, but still adds up to a difference of less than $50 for a 16GB RAM system. oddly, mwave is currently selling 4GB ECC Kingston RAM for $22.29 http://www.mwave.com.au/product/sku-aa64505-kingston_4gb_memory_ddr31333mhz_240pin_reg_ecc_kaca that price is so low I suspect a sale to get rid of an overstocked item, or maybe an error. BTW, all AMD CPU motherboards (even on home/hobbyist m/bs like from asus, asrock, gigabyte etc) support ECC and have done for several years. Some Intel home/hobbyist motherboards do too (until recently they disabled ECC on non-server CPUs as part of their usual artificial market segmentation practices). All server boards support ECC, of course. > > nowadays, i see them as first generation pool & volume management > > [...] > > True, but they also add complexity. Did you ever run debugfs on an > ext* filesystem? It's not that hard to do. I really don't want to > imagine running something similar on BTRFS or ZFS. zfs should prevent (detect and correct) the kind of small errors that are fixable manually with debugfs, and for anything more serious restoring from backup is the only practical solution. > > and as for lvextend, lvreduce, and lvresize - it's completely insane > > for there to be three tools that do basically the same job. > > It's pretty much standard in Unix to have multiple ways of doing it. yeah, from multiple alternative implementations, or by using variations of multiple small tools together in a pipeline. not generally in the same software package. when it is within the one package, it's generally for legacy reasons (i.e. backwards-compatibility, so as to not break scripts that were written to use the old tool) and clearly documented as such. > So it's a man page issue. documentation in general but yes, that's what i said. craig -- craig sanders <[email protected]> BOFH excuse #448: vi needs to be upgraded to vii _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
