Re: [Ext2-devel] [RFC] [PATCH] Reducing average ext2 fsck timethrough fs-wide dirty bit]

[Mingming Cao]

On Thu, 2006-03-23 at 00:11 +0100, Ingo Oeser wrote:
> Hi Mingming,
> 
> On Wednesday, 22. March 2006 19:16, Mingming Cao wrote:
> > ext3 block reservation takes a different approach.  It does block
> > reservation in memory, rather on disk as ext3 preallocation does.
> > Instead of maintaining a in-memory allocation bitmap, every inode has a
> > reservation window(default is 8blocks) which specifying the range the
> > disk blocks that has reserved for this inode. Blocks are actually
> > allocated from the window, rather directly from disk. New reservation
> > window will be created automatically if the existing window has no free
> > blocks.  There is a per-filesystem red-black reservation tree to
> > maintain all the reservation windows, and make sure blocks for inode 1
> > will not allocated in other inode's window.
> 
> Thanks for this nice and simple explanation!
> 
> Is it possible to start with an much bigger window?
> 

yes, it could! You could issuing ioctl with command EXT3_IOC_SETRSVSZ to
set the reservation size to match exactly what you want to reserve for.
The size here is the number of the filesystem blocks, rather in bytes.
As long as your application is doing a sequential like write
(allocation), the reservation window will dynamically doubled when
creating the new window. There is a upper limit of how big the window
could be

#define EXT3_MAX_RESERVE_BLOCKS         1024

The reason we have this limit is to prevent a file make a reservation of
the whole filesystem. But if this upper limit is too small for streaming
need, we could expand it to something bigger.

This is available since 2.6.10 kernel. 

> If I truncate a file to given size, this is usally a BIG hint, 
> what its actual disk space requirements are. So you can reserve just as much
> as linearly as possible.
> 
> Imagine a hard disk recorder with 2 MPEG streams and 2 meta data streams
> saturating the disk with writes. Any seek means, that the MPEG buffers fill up.
> 
> Once this degrades to a single fs block per seek, you are going to loose data.
> So fragmentation might not matter at all for reading, but it DOES matter for 
> writing large data streams.
> 
> Does it makes sense to threat truncates as reservations? 
> Maybe as an per-mount option?
> 

I am not sure to use truncate to indicating reservation/preallocation.
It's not obvious semantically and might complicated the code to do the
real truncating. That's why we use ioctl for reservation at the first
place.

> I would love that!
> 
> PS: If you think we need a broader audience, please include fsdevel 
> 	or sth. like that.
> 
> 
> Regards
> 
> Ingo Oeser

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/