Re: Any advantages of Unix formatting
Re: Any advantages of Unix formatting
- Subject: Re: Any advantages of Unix formatting
- From: Marcel Weiher <email@hidden>
- Date: Tue, 4 Sep 2001 11:23:28 +0200
On Tuesday, September 4, 2001, at 08:49 AM, Rosyna wrote:
This also begs the question. Which is better, auto defragmenting when
you need to store a file that requires at a minimum 12.5MBytes/second
or just letting the file fill the cracks?
And what happens when the file is MUCH larger than any available
contiguous block?
There seems to be some confusion about fragmentation and the things the
FFS does to avoid them:
1. Minimum Transfer Rates Requirements
It turns out that this is exactly where you want and desperately need a
fragmentation-avoiding file-system. A file-system that is allowed to
fragment can achieve higher 'best-case' transfer rates as long as it is
clean. However, 'best case' is absolutely useless when you have a
minimum transfer speed requirement, it is the *worst case* that you need
to optimize.
This is exactly what the Berkeley Fast File System (FFS) does: it
sacrifices a tiny amount of "best case" performance in order to vastly
improve the worst case (and average case as well for long running
file-systems).
2. Filling the cracks
This is exactly what you do not want to do when allocating blocks, as it
is exactly the crack-filling that gets you the non contiguous blocks
that slow you down. AFAIK, most modern file-systems have a "use next"
allocation strategy that will allocate from the end of the allocated
area where there are hopefully still some contiguous chunks available,
specifically leaving the gaps that may have formed further in front open
for later.
3. FFS 'auto defragmentation'
FFS does not have "auto defragmentation", which would be some sort of
de-fragger running interleaved with the file-system, and probably could
be slow. It simply has smart block-layout policies that *avoid*
fragmentation in the first place. The computational cost of this extra
work is, AFAIK, completely negligible and disappears behind disk-access
speeds.
However, there arer some indirect costs in that the FFS will, for
example, split up large files over several cylinder groups, incuring
small to medium seeks after a couple of Megabytes in large files that
could otherwise be contiguous. To put some numbers on this: for a disk
with 12MB/s sustained transfer rate and a small/medium seek time of 5ms
(very conservative), a cylinder group switch after ever 3MB would incur
an overhead of 5ms / 250ms = 2%. You'd need 60KB of buffering to mask
the effect.
4. Results
FFS file systems also suffer from fragmentation, but are amazingly
stable over time. An analysis of over 50 FFS filesystems at Harvard
ranging from 1-3 years in age showed less than 10% degradation for the
vast majority. The worst case was 30% on machine used as a USENET feed
(lots of small files).
--
Marcel Weiher Metaobject Software Research & Development
Get HOM at <
http://www.metaobject.com/downloads/Objective-C>