Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Sep 2015 10:27:09 -0453.75
From:      "William A. Mahaffey III" <wam@hiwaay.net>
To:        freebsd-questions@freebsd.org
Subject:   Re: Storage question
Message-ID:  <55F04E83.6070902@hiwaay.net>
In-Reply-To: <55F04D78.8070508@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> <20150909145820.c3b48aafad4f70553c1c1fd8@sohara.org> <55F0451A.5080709@hiwaay.net> <20150909160005.d3b84775c3d0748014a871e5@sohara.org> <55F04D78.8070508@hiwaay.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/09/15 10:21, William A. Mahaffey III wrote:
> On 09/09/15 10:06, Steve O'Hara-Smith wrote:
>> On Wed, 9 Sep 2015 09:47:00 -0453.75
>> "William A. Mahaffey III" <wam@hiwaay.net> wrote:
>>
>>> On 09/09/15 09:04, Steve O'Hara-Smith wrote:
>>>> On Wed, 9 Sep 2015 08:23:54 -0453.75
>>>> "William A. Mahaffey III" <wam@hiwaay.net> wrote:
>>>>
>>>>> 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
>>>>     My house fileserver (erm NAS in modern speak) is a dual core
>>>> Atom with 4GB. It manages a 4x2TB RAIDZ2 as well as a bunch of jails.
>>>> According to top it has 2432M for ARC (3592M altogether is wired).
>>>> Memory is tight but it's not swapping, and it doesn't no matter what
>>>> the load. Switching to your spec would be a hefty upgrade and would
>>>> almost certainly make things faster, but then most things can be made
>>>> faster with an extra expenditure.
>>>>
>>>>> especially robusto by today's standards, so I am staying w/ UFS.
>>>>> Someone
>>>>     If you have the opportunity then benchmark ZFS and see, if you
>>>> can run it the benefits are great.
>>>>
>>> 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, 
>>> hence my
>>> caution about it. If I go to ZFS, I (*think* I) use it for the whole
>>> drives, except for swap (possibly), & slice it up into
>>> 'partitions/slices/whatever' to do the install, right ? That was my
>>> take-away from reading the online pages about it. Maybe I need to
>>> rethink ....
>>     Yes that's essentially it - you assemble the raw storage you're
>> going to use into a zpool from which the storage that backs the 
>> filesystems
>> is drawn automatically. Once you have a zpool making a filesystem is 
>> very
>> cheap. The filesystems share the pool, if you want to cap them you 
>> can but
>> otherwise they're all limited by the pool. I've never filled a ZFS 
>> pool, I
>> don't think I want to.
>
>
> I have heard that filling your zpool is a *BAD* thing, but it can be 
> for any FS, just maybe a bit worse for ZFS. I am going to study that 
> option a bit more. The online docs all seem to show swap within the 
> zpool as well, does that work OK, performance wise ? It would simplify 
> installation, however I am planning to script that, so a bit of 
> 'extra' effort for separate swap partitions is not an issue. I have 
> always thought that separate swap partitions directly kernel managed 
> were the best for swap performance if/when it gets down to that, no ?


*Eeeeeeeek*, scratch that bit about 'all show swap under zpool', I was 
doing that from memory (last summer), sorry :-/ ....


-- 

	William A. Mahaffey III

  ----------------------------------------------------------------------

	"The M1 Garand is without doubt the finest implement of war
	 ever devised by man."
                            -- Gen. George S. Patton Jr.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55F04E83.6070902>