linux-kernel - RFC: Block size > PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060720105058.40166.qmail@web38507.mail.mud.yahoo.com>
Date:	Thu, 20 Jul 2006 03:50:58 -0700 (PDT)
From:	Levitsky Maxim <maximlevitsky@...oo.com>
To:	linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/