Hi Ian & all On Mon, 2007-06-25 at 09:45 -0400, Ian Murdock wrote: > Tim Foster wrote: > How does the system respond if it finds a bad block? Ideally, it > puts a copy somewhere else and keeps going, though if it runs > into this enough times, the user should be warned > (since it probably indicates impending catastrophic failure).
Good question - I'll have to punt that to the zfs developers. I'm not sure whether these ditto block corrections (eg. reading a bad block, recognising that, then finding a good copy of the data in a ditto block) get flagged as checksum errors at the moment or not. If they do, then they'll appear in "zpool status" output. There's ongoing work with ZFS and FMA to report/handle errors more elegantly. > Anywhere I can find numbers for 1. typical space savings; Depends on the data - I'm doing a quick experiment this afternoon, taking a snapshot of my root filesystem, and causing all the data to get re-written after compression was turned on, I'll report results when it's done. Adam also has some evidence in his blog post at: http://blogs.sun.com/ahl/entry/gzip_for_zfs_update (gzip compression support has gone back at this stage) > 2. typical performance degradation when compression is on, so > I have a better idea of the tradeoff? I don't know - as a desktop user, I haven't noticed a problem (sorry, that doesn't help) > > A commenter to Eric's post asks about potential impacts to battery-life > I would think the battery impact of reading the block from the disk > would far outweigh the battery impact of decompressing its contents, I suspect it depends on how large a cache ZFS uses for data, and also what CPU power management is active, and whether you're ramping up and down the cpu frequency all the time to do reads. It'd be interesting to measure this on a newish system (the laptop I have here is ancient, it's battery is past it's best, and it's only a 700mhz cpu) cheers, tim -- Tim Foster, Sun Microsystems Inc, Solaris Engineering Ops http://blogs.sun.com/timf _______________________________________________ indiana-discuss mailing list [email protected] http://opensolaris.org/mailman/listinfo/indiana-discuss
