On Fri, Apr 22, 2016 at 08:15:13AM +0800, Juan Karlo de Guzman wrote: > Moving forward, I was just wondering if you guys can help me out > utilizing the new technology that is natively supported when Ubuntu > 16.04 was released. It is the ZFS file system. That term is familiar for
ZFS is an amazing tool. To get the most benefit it's worth investing a few hours of reading; I suggest starting with the excellent series of blog posts by Aaron Toponce; https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/ I've got some advice, probably duplicates much of what's in the best practices pages: - Do not use dedup - Turn on lz4 compression for the top-level dataset when creating the pool, so all datasets get it by default - raidz1, raidz2, raidz3 are good for bulk storage but slow - mirrors are faster than raidz*, but also more expensive per terabyte - if you set ashift=12 now, even on 512byte hard drives, you'll be able to replace the 512byte drives with 4k drives in the future without performance loss. (ashift=12 apparenlty interacts poorly with raidz*.) - You cannot remove a vdev from a pool. Do not make mistakes with "zpool add". I've known five or six people who've accidentally added a single, bare, drive to their pool, turning it into roughly a raid0. The way out is to destroy the pool and recreate it from your backups. - If you're using 2tb drives or larger, it's really worth using raidz2 or raidz3, or three-way mirrors. Resilvering takes long enough. - Do not use dedup There's some details specific to Ubuntu's ZFS: - Ubuntu currently doesn't support root-on-zfs. This is a huge amount of work for a distribution to support, so I'm not surprised it didn't happen for 16.04 LTS. I recommend skipping it yourself, though I understand Richard Laager is preparing a HOWTO that may be useful if you want it anyway. - Ubuntu currently doesn't ship a cronjob or systemd job to schedule scrubs periodically. You really should do one yourself in the meantime. - Ubuntu currently doesn't ship a cronjob or systemd job to schedule snapshots. There's a lot to know about snapshots, so it's worth investigating tools that schedule snapshots automatically. It's truly astonishing what ZFS can do for you. In five minutes I was able to assemble nine 3TB drives into three 3-way mirrors for a total of 9TB of storage space, excellent redundancy, and excellent throughput that rivals consumer SSDs with large enough operations, compression, and checksums. All this is before using a l2arc or slog device to push speeds through the roof. > server has less than 4 GB of RAM then a 32-bit version of the server > should be used so that the memory won't be entirely wasted. Although, > feel free to correct me if I'm wrong. While it's true that 64bit systems on small memory VMs is slightly wasteful with pointer sizes, I think the benefits of 64 bit systems outweighs the downsides in almost all cases: - more CPU registers are free for use - more CPU instructions are available for more effecient use of data - better address space layout randomization makes certain kinds of attacks far less likely to succeed. - If all instances in your organization are 64 bit, your squid-deb-proxy or similar tools will have better hit rates with less storage. Have fun with your new toys :) I sure am. Thanks
signature.asc
Description: Digital signature
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
