On October 15, 2015, Michael Torrie wrote: > You don't have to set anything up. Managment of extents is part of the
> file systems that support it. Just do a mkfs.ext4 (or xfs or btrfs) and > you have it. Okay, I will just ask this part, and then I think I've gotten all the info I need, thanks. You mentioned changing the size of your extent on your Dual-Tuner MythTV box. What's the default extent size, and given the usage I mentioned (10-20% executable & data - which is where I was thinking of Data Dedup, 80-90% multi-media), would that be sufficent for my needs, do you think? If not, what would be a good extent size? Given the average size of some of the files I will be handling, I'm ALMOST tempted to make an extent size of 90MB, but that would be space wasting for the binary programs and such. Also, as just occured to me, speaking of extents. If I make, just say a 60MB extent, then write, say, 10 files that are 2MB ea when complete, that's 20 MB. Is XFS going to put all ten of those in one extent, or would I have 600MB allocated but only 20MB used? Just wondering. Oh, and of course the system will hav a UPS. That's a given for my system. :) Thanks! --- Dan On Thu, Oct 15, 2015 at 12:46 PM, Michael Torrie <[email protected]> wrote: > On 10/15/2015 09:19 AM, Nicholas Leippe wrote: > > Is bit flipping on storage media really a valid concern? > > My understanding of signal storage media is that at the lowest levels > there > > are significant amounts of ECC already in place to handle imperfections > in > > the media itself. Sectors that are detected as deteriorating are remapped > > before the data can no longer be read--thus the source of the S.M.A.R.T. > > "grown defects" counter. For SSDs, maybe this concern is now raising its > > ugly head again? > > I think it could be a concern. I don't think it's possible to reliably > detect them with SMART features. And when they do happen, without FS > checking blocks for checksums or hashes, they will be completely silent > corruptions. I've been carrying with data with me for nearly 30 years, > continuously copying my data from media to media as I went along. Given > the unreliable nature of yesterday's magnetic removable media, I'd be > surprised if there isn't the odd bit flipped in my data somewhere. It's > true things are much more reliable and self-correcting now. So maybe it > wouldn't matter. > > <snip> > > IMO, ext4 is the safest fs choice in Linux land today. Btrfs is simply > not > > ready yet. XFS while fairly mature still has some weird behaviors > reported > > occasionally, and ZFS while feature-full--and for which may be your cup > of > > tea--can be a little more effort to deal with. > > I agree for the most part. I've been using BtrFS for nearly four years > with very few issues and no apparent corruption. Being ready is > entirely a subjective measure. If everyone waits for some magical > threshold of "ready" then it can never quite get there. > > ZFS definitely has a learning curve. But once you get on to it, it's > hard to go back to other file systems. Nearly free snapshots is just so > addicting and powerful. When I worked at BYU our main file server was > ZFS and for backups we'd snapshot all the file systems first, and then > backup from the snapshot since the backup took much of the night. This > way we got a more coherent backup from a moment in time. Also we'd > snapshot home directories hourly, daily, monthly, and sometimes yearly. > No more calls from users saying I deleted a file this morning can you > recover it from backup for me? > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
