RFC: Block size > PAGE_SIZE

RFC: Block size > PAGE_SIZE

[Levitsky Maxim]

I have idea to lift software based limitation of 4K
maximum block size of block devices.

There are some devices that have bigger that 4K block
size. The most notable are packet driven CD/DVD
recorders, but for example Flash chips cannot erase
blocks that are bigger that 64K of even more.

The main reason for this limitation is the fact that
both buffer and page cache are stored in pages, and
each page have set of buffers that is pointed by it's
private field. So a page must contain at least one
buffer and thus buffer cannot be larger that 4K , the
IA32 default page size.

The extent based filesystems can also benefit from
bigger block size , they will be able to read a
cluster at time

My idea is storing a sector in number of pages.

Each buffer_head will have addition filed ->next that
will point in circuit to next buffer_head that stores
data from the same sector 
actually it is possible not to use this ->next field 
because buffer_heads are linked in list of same page
buffer_heads. but im my case page will contain only
one buffer head so I can reuse this field.

>From FS point of view , it may look difficult to
implement big block sizes because filesystems are not
aware of ether linked list of buffer_heads nor of big
block sizes.

But this can be fixed very easy. set_blocksize will
have addition flags parameter and all filesystems that
are unaware of new design or don't need big block
sized will pass 0 as this parameter. and they won't be
allowed to use new design. New or modified filesystems
will pass a flag and bigger that 4K block size to this
function, and then after each __getblk they will
examine not only returned buffer_head but also the
linked ones.

default address space operations will be changed too
to support both small and big block sizes. 

I thought a lot about changes is those functions but
it seems that changes small enough.

I didn't yet implemented this idea , because I want to
know whenever you like this idea or not. After all
this is not a simply work. 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: RFC: Block size > PAGE_SIZE

[Jörn Engel]

On Thu, 20 July 2006 03:50:58 -0700, Levitsky Maxim wrote:
> 
> I have idea to lift software based limitation of 4K
> maximum block size of block devices.
> 
> There are some devices that have bigger that 4K block
> size. The most notable are packet driven CD/DVD
> recorders, but for example Flash chips cannot erase
> blocks that are bigger that 64K of even more.

s/bigger/smaller/

Flash is a bad example.  Even if the block layer and say ext2 could
deal with 64k block size, using ext2 as a flash filesystem would still
be an extremely bad idea for several other reasons.  Not sure about
the CD/DVD case, but according to my half-knowledge the same is true
there.

> The extent based filesystems can also benefit from
> bigger block size , they will be able to read a
> cluster at time

Already the case, afaics.

> Each buffer_head will have addition filed ->next that
> will point in circuit to next buffer_head that stores
> data from the same sector 

buffer_head is considered deprecated.  You could have a look at
struct bio and reconsider whether your idea is a good one.

> I didn't yet implemented this idea , because I want to
> know whenever you like this idea or not. After all
> this is not a simply work. 

There can be some benefit in having larger block sizes.  For ext2, it
would increase limits like the maximum file size, decrease the amount
of metadata and have some nice effects on caches (smaller data is as
good as bigger caches and bigger bandwidth in one).

But there are disadvantages as well, most notably the wasted space for
small files increases.

And overall, 99% of the problem lies within an individual filesystem,
so working on the block layer doesn't help much.  If you want to
follow your idea, you should pick a filesystem, learn as much about it
as you can and then change this filesystem.  And after your changes,
measure whether they have beneficial effects.

Jörn

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
-- Brian W. Kernighan