OT: file systems was Re: Can filepro do drill downs like acess?

[Jay R. Ashworth]

On Fri, Mar 26, 2004 at 05:28:09PM -0500, Bill Vermillion wrote:
> > > consumer/desktop drives].  The high-end high-capacity SCSI's are in
> > > the $6+ per GB.
> 
> > Seagate's Cheetah-164 is about $800 right now. That is,
> > actually, $.50 a gig.
> 
> I saw your later correction and my figure was based on $1200 that
> I researched on a 16k Cheetah with Fiber-channel interface. 

Indeed.

Said correction was on a Cheetah (10Krpm) 164GB Ultra-160 that is about
$800 or so this month.

> > Actaully, most of that is being done with journalling
> > filesystems, these days, which are effectively the application
> > of transactions to filesystem updates: the filesystem
> > structure's sanity is preferred at the expense of the data, in
> > the event of a crash.
> 
> Actually the way I understand it, journalling is going to protect
> the data more but at the expense of a coherent file system in case
> of a crash.  And to be sure of stability you need to run a
> journalling system in a synchronous mode with then sacrifices
> performance.

"at the expense of" sounds like you think a JFS protects the data over
the structure, which is not the understanding I have.

I suppose, on reflection, it's a little of both.  JFSen tend to reduce
the window of exposure during which the logical state of the filesystem
is inconsistent by making use of the journal.

> This is why McKusick [one of the principle architects of BSD for
> years and one of the authors of the 4.2, 4.3, and 4.4 series of
> books explaining BSD before it became unencumberd] developed the
> softupdates.  It sets file system integrity as it's highest
> priority and does meta data updates in a synchronous mode, and
> planned carefully. THere is about a 40 page paper on that at one of
> the University sites.

I'll have to look; thanks.

> Then after meta-data is written the rest of the file system is
> handled in lazy mode.  It's interesting to perform an rm -r on a
> source tree of about 350 MB and have the prompt returned back in a
> matter of seconds, but then watch the blocks free up slowly -
> sometimes taking as long as 2 minutes.   Freeing block is not a
> high priority but ensuring the FS is stable is.

indeed.

>     5. Implementation of Background "fsck"
> 
>    Background "fsck" runs by taking a snapshot then running its
>    traditional algorithms over the snapshot. Because the snapshot is
>    taken of a completely quiescent filesystem, all of whose dirty blocks
>    have been written to disk, the snapshot appears to "fsck" to be
>    exactly like an unmounted raw disk partition.  ...

That *sounds* logically impossible.  But this *is* Kirk.  	'll
have to go read it.

> I hope you found that interesting.  I've waited a long time for
> relatively small FS'es to have an fsck performed, I'd really not
> like to wait while a 250 GB file system [as an example] completes
> it's fsck.  And users waiting for the system to come back up don't
> like it either.

True, but again, JFS's usually don't require it.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

        "They had engineers in my day, too."  -- Perry Vance Nelson