From: Andrew Morton <akpm@zip.com.au>
To: Christoph Hellwig <hch@infradead.org>
Cc: Steve Lord <lord@sgi.com>, Anton Altaparmakov <aia21@cantab.net>,
Urban Widmark <urban@teststation.com>,
linux-fsdevel@vger.kernel.org
Subject: Re: fs requirements for loop device?
Date: Mon, 13 May 2002 14:43:25 -0700 [thread overview]
Message-ID: <3CE0337D.AFF02E2@zip.com.au> (raw)
In-Reply-To: 20020513174132.A23112@infradead.org
Christoph Hellwig wrote:
>
> On Mon, May 13, 2002 at 09:43:05AM -0500, Steve Lord wrote:
> > > ->readpage in address space operations as it uses that directly
> > > (apparently, I never looked at it).
> >
> > You need prepare_write and commit_write too.
>
> And even worse you need locking rules similar to the generic file
> operations in mm/filemap.c, this was for example biteing GFS/OpenGFS.
>
> In short: loop.c is a horrible mess nad usually only works for
> fileystems using generic_file_read/generic_file_write, an exceptions
> is XFS that has very similar operations to those, but due to lack of
> takeing a lock I'm still not sure whether is really is 100% correct.
>
> An yes, I think the abuse of do_generic_file_read is a big mistake,
> it should never have been exported from filemap.c.
>
Can anyone point at a reason why loop shouldn't use the
->read() and ->write() methods of the backing file's
file_operations?
AFAICS, that fixes everything, including tmpfs.
-
next prev parent reply other threads:[~2002-05-13 21:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33.0205131610410.1822-100000@cola.enlightnet.lo cal>
2002-05-13 14:36 ` fs requirements for loop device? Anton Altaparmakov
2002-05-13 14:43 ` Steve Lord
2002-05-13 16:41 ` Christoph Hellwig
2002-05-13 21:43 ` Andrew Morton [this message]
2002-05-13 23:21 ` Urban Widmark
2002-05-13 23:47 ` Andrew Morton
2002-05-13 23:58 ` Alexander Viro
2002-05-14 0:13 ` Andrew Morton
2002-05-14 7:01 ` Christoph Hellwig
2002-05-14 9:20 ` Urban Widmark
2002-05-13 14:24 Urban Widmark
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=3CE0337D.AFF02E2@zip.com.au \
--to=akpm@zip.com.au \
--cc=aia21@cantab.net \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lord@sgi.com \
--cc=urban@teststation.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.