From: Nathan Scott <nathans@sgi.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
Andrew Morton <akpm@osdl.org>,
linux-fsdevel@vger.kernel.org, linux-xfs@oss.sgi.com,
viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: Advice sought on how to lock multiple pages in ->prepare_write and ->writepage
Date: Tue, 1 Feb 2005 09:00:02 +1100 [thread overview]
Message-ID: <20050131220002.GB9377@frodo> (raw)
In-Reply-To: <OFD4DAAE59.6685BB61-ON88256F97.007D2911-88256F97.007DCD5B@us.ibm.com>
On Fri, Jan 28, 2005 at 02:53:41PM -0800, Bryan Henderson wrote:
> >Just putting up my hand to say "yeah, us too" - we could also make
> >use of that functionality, so we can grok existing XFS filesystems
> >that have blocksizes larger than the page size.
>
> IBM Storage Tank has block size > page size and has the same problem. This
> is one of several ways that Storage Tank isn't generic enough to use
> generic_file_write() and generic_file_read(), so it doesn't. That's not a
> terrible way to go, by the way. At some point, making the generic
> interface complex enough to handle every possible filesystem becomes worse
> than every filesystem driver having its own code.
Supporting blocksizes larger than the pagesize is a pretty common
thing on other Unices, I don't see any reason why there shouldn't
be support for this in the generic routines. Especially if there
are tricky aspects to interacting with the page cache and getting
the locking right.
OOC, have you folks measured any performance improvements at all
using larger IOs (doing multi-page bios?) with larger blocksizes?
thanks.
--
Nathan
next prev parent reply other threads:[~2005-01-31 22:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 10:48 Advice sought on how to lock multiple pages in ->prepare_write and ->writepage Anton Altaparmakov
2005-01-28 0:58 ` Andrew Morton
2005-01-28 5:06 ` Nathan Scott
2005-01-28 11:08 ` Anton Altaparmakov
2005-01-28 22:53 ` Bryan Henderson
2005-01-31 22:00 ` Nathan Scott [this message]
2005-01-31 23:46 ` Bryan Henderson
2005-02-01 0:10 ` Sonny Rao
2005-02-01 1:32 ` Bryan Henderson
2005-02-01 16:49 ` Sonny Rao
2005-02-01 1:29 ` Matthew Wilcox
2005-01-28 10:43 ` Anton Altaparmakov
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=20050131220002.GB9377@frodo \
--to=nathans@sgi.com \
--cc=aia21@cam.ac.uk \
--cc=akpm@osdl.org \
--cc=hbryan@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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