From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Namjae Jeon <linkinjeon@gmail.com>,
elder@kernel.org, Namjae Jeon <namjae.jeon@samsung.com>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org,
bpm@sgi.com, adilger.kernel@dilger.ca, a.sangwan@samsung.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/3] fs: Introduce new flag FALLOC_FL_COLLAPSE_RANGE
Date: Wed, 31 Jul 2013 21:07:52 -0400 [thread overview]
Message-ID: <20130801010751.GD11378@thunk.org> (raw)
In-Reply-To: <20130801005447.GS13468@dastard>
On Thu, Aug 01, 2013 at 10:54:47AM +1000, Dave Chinner wrote:
> > It's not just the range that it's operating on, but also the region
> > beyond the range that's been collapsed out.
>
> Yes, that's part of "the range that it is operating over".
>
> > A quick eyeball of the patch didn't seem to show any code that handled
> > this, which is why I asked the question.
>
> Right, but really it's the least of the problems I've noticed - the
> XFS code is fundamentally broken in many ways - once I've finished
> commenting on it, I'll have a quick look to see if the ext4 code has
> the same fundamental flaws....
Well, the fundamental flaw of potential races if the file being
collapsed has been mmap'ed and there is another process making changes
beyond the range that is being collapsed is I suspect one that is
going to be very hard to solve, short of not allowing the collapse
while there are any read/write mmap's for the file in question.
And I would think these sorts of VM issues should be handled with some
generic library functions, instead of reimplementing them from scratch
in each file system.
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-08-01 1:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 14:42 [PATCH 1/3] fs: Introduce new flag FALLOC_FL_COLLAPSE_RANGE Namjae Jeon
2013-07-31 22:01 ` Theodore Ts'o
2013-08-01 0:23 ` Dave Chinner
2013-08-01 0:46 ` Theodore Ts'o
2013-08-01 0:54 ` Dave Chinner
2013-08-01 1:07 ` Theodore Ts'o [this message]
2013-08-01 2:59 ` Dave Chinner
2013-08-01 4:06 ` Theodore Ts'o
2013-08-01 4:32 ` Dave Chinner
2013-08-01 0:22 ` Dave Chinner
2013-08-01 5:07 ` Namjae Jeon
2013-08-02 2:37 ` Dave Chinner
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=20130801010751.GD11378@thunk.org \
--to=tytso@mit.edu \
--cc=a.sangwan@samsung.com \
--cc=adilger.kernel@dilger.ca \
--cc=bpm@sgi.com \
--cc=david@fromorbit.com \
--cc=elder@kernel.org \
--cc=hch@infradead.org \
--cc=linkinjeon@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).