Messages in this thread | | | Date | Thu, 20 Jul 2006 03:50:58 -0700 (PDT) | From | Levitsky Maxim <> | Subject | RFC: Block size > PAGE_SIZE |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |