Re: Background fsck

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Mon, Jan 19, 2004 at 09:28:30AM -0800, Matthew Dillon wrote:
> :The journal should at least be spread over the disk. E.g. the seek
> :argument is somewhat weak since you need (a) to write the meta-data
> :to disk anyway and seek for that and (b) to seek for the normal read
> :activity. 
>  
>     There is no reason to spread a meta-data journal all over the disk,
>     you'll just make it go slower.  All you need is a fixed area of whatever
>     size you choose to use as a circular FIFO.  e.g. 10MB of space would
>     be sufficient.
> 
>     The seek argument is paramount.  99.9% of the time a disk spends doing
>     an I/O is seeking.  The actual write takes no time at all.  It's the
>     seek that matters.

Yeah, but seek time is not constant. Nor are the actual writes spread
over the complete disk. well, hopefully at least. what I meant with
spreading the journal is simply to add the fs code an option to use
a nearer journal part. E.g. split the 16MB (looks better) log into
4 MB pieces looked in the different areas of the disk. The option to
split the journal into pieces becomes useful if you have RAID or similiar
means in place, which can effect the overall performance dramatically.

[snip]
>     In otherwords, A meta-data journal does not slow things down in the
>     least.

That's what I'm not sure of. There is at least one example of prior
art -- ext2/ext3. IIRC many filesystem benchmark give ext3 a worse
performance. But only implementing this properly and benchmarking it
will give us truth.

> 
> :That's the problematic part. For the background fsck there is one
> :assumption which must hold true. At one time or another the fsck
> :must find any ressource. That's what complicates the process a bit.
> :Doing it in kernel would simplify things a bit, but the basic problem
> :is the same. But anyway could you live with allowing the R/W mount
> :of dirty softdep fs? You can run the fsck later, it is only needed to
> :recollect some unreferenced inodes and blocks.
>  
>     I really dislike a R/W mount on anything dirty.
> 
>     A journal removes the need entirely... recovery would not take very
>     long at all so you wouldn't have to support background fscking.

Technically speaking, the journal just saves the garbage collection.
The log-replay provides the same level of functionallity as the
background fsck. The consistence of the filesystem itself is already
there (with softdep).

Joerg

> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>
> 
> :>     So, how can I (a) convince you that a filesystem journal is the way to
> :>     go and (b) maybe get you to write it ?  :-) :-) (!)
> :
> :I will dig into David's journal code anyway, since this is at least
> :interesting. I haven't changed my PoV concerning Journal vs. Softdep yet,
> :but we should get some real performance numbers once we have both
> :Journaling and Softdeps in tree.
> :
> :Joerg