From: Levitsky Maxim <maximlevitsky@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: RFC: Block size > PAGE_SIZE
Date: Thu, 20 Jul 2006 03:50:58 -0700 (PDT) [thread overview]
Message-ID: <20060720105058.40166.qmail@web38507.mail.mud.yahoo.com> (raw)
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
next reply other threads:[~2006-07-20 10:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-20 10:50 Levitsky Maxim [this message]
2006-07-27 9:17 ` Jörn Engel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060720105058.40166.qmail@web38507.mail.mud.yahoo.com \
--to=maximlevitsky@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®