From: Theodore Tso <tytso@mit.edu>
To: Jiaying Zhang <jiayingz@google.com>
Cc: Andreas Dilger <adilger@sun.com>,
Frank Mayhar <fmayhar@google.com>,
Eric Sandeen <sandeen@redhat.com>,
Curt Wohlgemuth <curtw@google.com>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: Question on fallocate/ftruncate sequence
Date: Sat, 29 Aug 2009 22:52:50 -0400 [thread overview]
Message-ID: <20090830025250.GA25768@mit.edu> (raw)
In-Reply-To: <5df78e1d0908281740w7bc0f283x5004ca5b231b3af5@mail.gmail.com>
On Fri, Aug 28, 2009 at 05:40:54PM -0700, Jiaying Zhang wrote:
> --- .pc/fallocate_keepsizse.patch/fs/attr.c 2009-08-28 15:38:46.000000000 -0700
> +++ fs/attr.c 2009-08-28 17:01:04.000000000 -0700
> @@ -68,7 +68,8 @@ int inode_setattr(struct inode * inode,
> unsigned int ia_valid = attr->ia_valid;
>
> if (ia_valid & ATTR_SIZE &&
> - (attr->ia_size != i_size_read(inode)) {
> + (attr->ia_size != i_size_read(inode) ||
> + (inode->i_flags & FS_KEEPSIZE_FL))) {
> int error = vmtruncate(inode, attr->ia_size);
> if (error)
> return error;
Instead of doing this in the generic code, it really should be done in
ext4_setattr. Technically speaking, we don't actually need the
FS_KEEPSIZE_FL to solve this problem; instead we can simply have the
ext4 code look in the extent tree to see if there are any blocks
mapped beyond the logical block:
i_size_read(inode) >> inode->i_sb->s_blocksize_bits
Having a flag as Andreas suggested does help with the issue of e2fsck
noticing whether or not i_size is incorrect (and should be fixed) or
the file has been extended. So keeping having the flag is an OK thing
to do, but we need to be careful about a particularly subtle
overloading problem. The flags FS_*_FL as defined in
include/linux/fs.h are technically only for in-memory use. The ext4
on-disk format flags is EXT4_*_FL, and defined in ext4.h.
The flags were originially defined for use in ext2/3/4, but later on
other filesystems adopted those flags so that e2fsprogs's chattr and
lsattr programs could be used for their filesystems as well. It just
so happens that for ext2/3/4 the on-disk encoding of those flags in
the in-memory encoding of those flags in i_flags are the same, but
that means that the flags need to be defined in both places to avoid
assignment overlaps. We also need to be clear whether the flags are
internal flags for ext4's use only, or flags meant for use by all
filesystems. This is why the testing for FS_KEEPSIZE_FL in fs/attr is
particularly bad, if the flag are going to be set in fs/ext4/extents.c.
It's better to define the flag as EXT4_KEEPSIZE_FL, and to use it as
EXT4_KEEPSIZE_FL, but make a note of that bitfield position as being
reserved in include/linux/fs.h.
- Ted
next prev parent reply other threads:[~2009-08-30 2:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-20 16:36 Question on fallocate/ftruncate sequence Curt Wohlgemuth
2009-07-20 22:45 ` Eric Sandeen
2009-07-21 21:29 ` Frank Mayhar
2009-07-21 21:54 ` Andreas Dilger
2009-07-22 16:24 ` Frank Mayhar
2009-07-22 23:10 ` Frank Mayhar
2009-07-23 3:05 ` Eric Sandeen
2009-07-23 16:27 ` Frank Mayhar
2009-07-23 17:00 ` Eric Sandeen
2009-07-23 18:05 ` Frank Mayhar
2009-07-23 21:56 ` Andreas Dilger
2009-07-23 22:46 ` Frank Mayhar
2009-08-28 18:42 ` Jiaying Zhang
2009-08-28 19:40 ` Andreas Dilger
2009-08-28 21:44 ` Jiaying Zhang
2009-08-28 22:14 ` Andreas Dilger
2009-08-29 0:40 ` Jiaying Zhang
2009-08-30 2:52 ` Theodore Tso [this message]
2009-08-31 19:40 ` Jiaying Zhang
2009-08-31 21:56 ` Andreas Dilger
2009-08-31 23:33 ` Jiaying Zhang
2009-09-02 8:41 ` Andreas Dilger
2009-09-03 5:20 ` Jiaying Zhang
2009-09-03 5:32 ` Jiaying Zhang
2009-09-24 5:27 ` Jiaying Zhang
2009-09-25 7:35 ` Andreas Dilger
2009-09-25 22:08 ` Jiaying Zhang
2009-09-29 19:15 ` Eric Sandeen
2009-09-29 19:38 ` Jiaying Zhang
2009-09-29 19:55 ` Eric Sandeen
2009-09-30 8:10 ` Andreas Dilger
2009-10-02 22:10 ` Jiaying Zhang
2009-10-02 22:29 ` Eric Sandeen
2009-10-02 23:21 ` Jiaying Zhang
2009-07-23 19:48 ` Question on fallocate/ftruncate sequence (and flags) Frank Mayhar
2009-07-23 20:37 ` Eric Sandeen
2009-07-23 21:01 ` Frank Mayhar
2009-07-29 15:29 ` Jan Kara
2009-07-29 15:59 ` Frank Mayhar
2009-07-23 21:53 ` Andreas Dilger
2009-07-23 23:33 ` Greg Freemyer
2009-07-21 22:03 ` Question on fallocate/ftruncate sequence Eric Sandeen
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=20090830025250.GA25768@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=curtw@google.com \
--cc=fmayhar@google.com \
--cc=jiayingz@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.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).