Re: ZFS from Sun, what's about a new FS for OpenVMS
From: Bill Todd (billtodd_at_metrocast.net)
Date: 11/10/05
- Next message: Richard Maher: "failSAFE IP - Looks good! Who's using it? (and why/why-not)"
- Previous message: Hein RMS van den Heuvel: "Re: EXQUOTA with TCP/IP $QIO io$_acpcontrol gethostbyname"
- In reply to: Chuck McCrobie: "Re: ZFS from Sun, what's about a new FS for OpenVMS"
- Next in thread: Bill Todd: "Re: ZFS from Sun, what's about a new FS for OpenVMS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 10 Nov 2005 00:16:51 -0500
Chuck McCrobie wrote:
> Hoff Hoffman wrote:
>
>> Alan Greig wrote:
>>
>>>
>>> A better link is http://www.hpl.hp.com/hpjournal/dtj/vol8num2/toc.htm
>>> which is direct link to Digital Technical Journal Volume 8 No 2
>>> discussing Spiralog.]
>>>
>>> The official story is that it was cancelled because of insurmountable
>>> performance problems - the reason the developers gave is that the
>>> project was cancelled to save money and all staff on the project made
>>> redundant. All cited performance issues were already being addressed
>>> and were expected in the first release. At least that's what the team
>>> told me just before they were sacked.
>>
>>
>>
>> Spiralog shipped various releases.
>>
>> The limitations look to be inherent within log file system designs.
>>
>>
>
> IF I remember correctly, log file systems were great until the garbage
> collector had to run. Then performance fell greatly while it tried to
> free up large amounts of contiguous space.
That's an implementation, not an intrinsic, deficiency. The first part
of the solution is obviously to collect as a fairly continuous
background activity in order to avoid sudden changes in performance, but
beyond that (and especially important as free space starts to become
tight) is to use a hierarchy of 'log' spaces (at least 2) such that only
the first, most volatile level requires any significant reshuffling
(with the 'colder' data - which should be the vast majority - just
sitting in place in subsidiary levels which aren't even looked at during
the primary shuffling activity and which get shuffled themselves at even
lower priority to reclaim the far less frequent changes in allocation
there).
This does of course assume a set of segmented rather than a physically
linear logs, but Spiralog's log was segmented so could have relatively
easily been modified in this manner.
(I think that approaches which attain somewhat similar ends without
forcing the stored data into a log motif are better still, though - and
ZFS appears to be one such.)
- bill
- Next message: Richard Maher: "failSAFE IP - Looks good! Who's using it? (and why/why-not)"
- Previous message: Hein RMS van den Heuvel: "Re: EXQUOTA with TCP/IP $QIO io$_acpcontrol gethostbyname"
- In reply to: Chuck McCrobie: "Re: ZFS from Sun, what's about a new FS for OpenVMS"
- Next in thread: Bill Todd: "Re: ZFS from Sun, what's about a new FS for OpenVMS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]