Hello, We have a new Thor here with 24TB of disk in (first of many, hopefully). We are trying to determine the bext practices with respect to file system management and sizing. Previously, we have tried to keep each file system to a max size of 500GB to make sure we could fit it all on a single tape, and to minimise restore times and impact should we experience some kind of volume corruption. With zfs, we are re-evaulating our working practices.
A few questions then. Apologies if these have been asked recently, I went back through a month's worth of posts and couldn't see anything. I've also read the best practices guide here: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#ZFS_Administration_Considerations Pointers to additional info are most welcome! 1. Do these kinds of self-imposed limitations make any sense in a zfs world? 2. What is the 'logical corruption boundry' for a zfs system - the filesystem or the zpool? 3. Are there scenarios apart from latency sensitive applications (e.g. Oracle logs) that warrant separate zpools? One of our first uses for our shiney new server is to hold about 5TB of data which logically belongs on one share/mount, but has historically been partitioned up into 500GB pieces. The owner of the data is keen to see it available in one place, and we (as the infrastructure team) are debating whether it's a sensible thing to allow. Thanks for any advice/wisdom you may have... Cheers, Paul _______________________________________________ zfs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
