Date: Wed, 09 Sep 2015 17:13:11 -0400 From: Quartz <quartz@sneakertech.com> To: "William A. Mahaffey III" <wam@hiwaay.net> Cc: freebsd-questions@freebsd.org Subject: Re: Storage question Message-ID: <55F0A0E7.1060709@sneakertech.com> In-Reply-To: <55F031A0.40500@hiwaay.net> References: <55EF3D23.5060009@hiwaay.net> <20150908220639.20412cbd@gumby.homeunix.com> <55EF5409.8020007@yahoo.com> <55EFC2DA.3020101@hiwaay.net> <08B351DD-AA48-4F30-B0D6-C500D0877FB3@lafn.org> <55F02DC8.7000706@hiwaay.net> <20150909150626.5c3b99e5.freebsd@edvax.de> <55F031A0.40500@hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> I like ZFS in principal (it's one of the things that attracted me to > FreeBSD about a year ago), but, as someone else noted, it seems to > require lots of RAM & possibly CPU for best effect. The MythTV box is an > AMD A4-5000, 1.5 GHz quad-core jaguar, w/ 16 GB of RAM, which isn't > especially robusto by today's standards, Err..... this is just a home fileserver/mediabox, right? That's PLENTY of horsepower. ZFS has a reputation for being ram hungry, but that's mainly the ARC trying to hold a copy of a bazillion files being used by dozens of users or you turn on live dedupe. Likewise, CPU usage only gets high if you set max compression. You're very unlikely to be pushing it like that. > I am quite amenable to running ZFS, I just don't want to have to > abandon it & return to UFS if my system proves inadequate for the > task, Unless this machine needs to serve dozen of streams to dozens of users, you'll be fine, really. >If I go to ZFS, I (*think* I) use it > for the whole drives, That's an issue of minor debate. Currently ZFS has no capability to shrink the size of a pool once created. If a drive dies, the replacement MUST be precisely equal or greater in size- even one sector smaller won't work. Since you can't guarantee exact sector count (especially between different manufacturers) you're kinda stuck only buying bigger drives.... although you're probably going to be doing that anyway, so to most people it's a moot point. There are several ways around this by playing with fake partitions and GEOM and stuff, I can mail you off list if you're interested. >& slice it up into > 'partitions/slices/whatever' to do the install, right ? Not "partitions" in the traditional sense of the word. A ZFS pool is divided up into "datasets", which are kind of a cross between a partition and a directory. Datasets can have their own individual quotas and compression and backup copies and whatever. The 10.x installer can set all this up for you if you use the 'root on zfs' wizard. You can look at what it does and then learn how to do it manually on 9.x >I have heard that filling your zpool is a *BAD* thing ZFS is a copy-on-write fs, which means it never directly overwrites things. If you completely fill up the drive there's no space left to write any changes (which includes file deletions!) and you get stuck. This isn't as big a deal as it sounds though since there's a bunch of tricks available to prevent it, ie; quotas, reservations, dummy datasets, etc. (I think setting 'refreservation=1G' is the current preferred way these days). > could you amplify on that point about no compression w/ MythTV As others said, video files are already compressed. However, the power of ZFS is that with datasets you can selectively enable compression as you want. I'd STRONGLY suggest leaving compression enabled for the system files, and just disabling it for the directories that hold the video data. Make sure you enable this option *BEFORE* you start writing files though, ZFS can only compress stuff as it's writing it, not afterwards. (It's almost a moot point anyway, since the lightweight lz compression option is so fast it hardly uses enough CPU to be noticeable. You could just enable it globally and be fine.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F0A0E7.1060709>