hardware for home use large storage

[Alexander Leidinger]

Quoting Jeremy Chadwick <freebsd at jdc.parodius.com> (from Mon, 15 Feb  
2010 01:07:56 -0800):

> On Mon, Feb 15, 2010 at 10:49:47AM +0200, Dan Naumov wrote:
>> > I had a feeling someone would bring up L2ARC/cache devices.  This gives
>> > me the opportunity to ask something that's been on my mind for quite
>> > some time now:
>> >
>> > Aside from the capacity different (e.g. 40GB vs. 1GB), is there a
>> > benefit to using a dedicated RAM disk (e.g. md(4)) to a pool for
>> > L2ARC/cache?  The ZFS documentation explicitly states that cache
>> > device content is considered volatile.
>>
>> Using a ramdisk as an L2ARC vdev doesn't make any sense at all. If you
>> have RAM to spare, it should be used by regular ARC.
>
> ...except that it's already been proven on FreeBSD that the ARC getting
> out of control can cause kernel panics[1], horrible performance until

There are other ways (not related to ZFS) to shoot into your feet too,  
I'm tempted to say that this is
  a) a documentation bug
and
  b) a lack of sanity checking of the values... anyone out there with  
a good algorithm for something like this?

Normally you do some testing with the values you use, so once you  
resolved the issues, the system should be stable.

> ZFS has had its active/inactive lists flushed[2], and brings into

Someone needs to sit down and play a little bit with ways to tell the  
ARC that there is free memory. The mail you reference already tells  
that the inactive/cached lists should maybe taken into account too (I  
didn't had a look at this part of the ZFS code).

> question how proper tuning is to be established and what the effects are
> on the rest of the system[3].  There are still reports of people

That's what I talk about regarding b) above. If you specify an arc_max  
which is too big (arc_max > kmem_size - SOME_SAVE_VALUE), there should  
be a message from the kernel and the value should be adjusted to a  
save amount.

Until the problems are fixed, a MD for L2ARC may be a viable  
alternative (if you have enough mem to give for this). Feel free to  
provide benchmark numbers, but in general I see this just as a  
workaround for the current issues.

> disabling ZIL "for stability reasons" as well.

For the ZIL you definitively do not want to have a MD. If you do not  
specify a log vdev for the pool, the ZIL will be written somewhere on  
the disks of the pool. When the data hits the ZIL, it has to be really  
on a non-volatile storage. If you lose the ZIL, you lose data.

> The "Internals" section of Brendan Gregg's blog[4] outlines where the
> L2ARC sits in the scheme of things, or if the ARC could essentially
> be disabled by setting the minimum size to something very small (a few
> megabytes) and instead using L2ARC which is manageable.

At least in 7-stable, 8-stable and 9-current, the arc_max now really  
corresponds to a max value, so it is more of providing a save arc_max  
than a minimal arc_max. No matter how you construct the L2ARC, ARC  
access will be faster than L2ARC access.

> [1]:  
> http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211009.html
> [2]:  
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053949.html
> [3]:  
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055073.html
> [4]: http://blogs.sun.com/brendan/entry/test

Bye,
Alexander.

-- 
BOFH excuse #439:

Hot Java has gone cold

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137