From: Eric Sandeen <sandeen@redhat.com>
To: Mingming <cmm@us.ibm.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] Add flag to files with blocks intentionally past EOF
Date: Tue, 19 Jan 2010 21:58:47 -0600 [thread overview]
Message-ID: <4B567F77.5030103@redhat.com> (raw)
In-Reply-To: <1263948377.3954.2.camel@mingming-laptop>
Mingming wrote:
> On Tue, 2010-01-19 at 15:45 -0600, Eric Sandeen wrote:
>> From: Jiaying Zhang <jiayingz@google.com>
>>
>> fallocate() may potentially instantiate blocks past EOF, depending
>> on the flags used when it is called.
>>
>> e2fsck currently has a test for blocks past i_size, and it
>> sometimes trips up - noticeably on xfstests 013 which runs fsstress.
>>
>> This patch from Jiayang does fix it up for me - it (along with
>> e2fsprogs updates and other patches recently from Aneesh) has
>> survived many fsstress runs in a row.
>>
>> The setattr interface may also be used to clear the flag and remove
>> any blocks past EOF.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> (just resending this since it probably got lost in the previous
>> thread - Jiaying didn't have a SOB line, but maybe that should
>> be added. I have included the proper From: line for authorship)
>>
>> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
>> index 874d169..4c7cd9b 100644
>> --- a/fs/ext4/ext4.h
>> +++ b/fs/ext4/ext4.h
>> @@ -284,10 +284,11 @@ struct flex_groups {
>> #define EXT4_TOPDIR_FL 0x00020000 /* Top of directory hierarchies*/
>> #define EXT4_HUGE_FILE_FL 0x00040000 /* Set to each huge file */
>> #define EXT4_EXTENTS_FL 0x00080000 /* Inode uses extents */
>> +#define EXT4_EOFBLOCKS_FL 0x00400000 /* Blocks allocated beyond EOF (bit reserved in fs.h) */
>> #define EXT4_RESERVED_FL 0x80000000 /* reserved for ext4 lib */
>>
>> -#define EXT4_FL_USER_VISIBLE 0x000BDFFF /* User visible flags */
>> -#define EXT4_FL_USER_MODIFIABLE 0x000B80FF /* User modifiable flags */
>> +#define EXT4_FL_USER_VISIBLE 0x004BDFFF /* User visible flags */
>> +#define EXT4_FL_USER_MODIFIABLE 0x004B80FF /* User modifiable flags */
>>
>> /* Flags that should be inherited by new inodes from their parent. */
>> #define EXT4_FL_INHERITED (EXT4_SECRM_FL | EXT4_UNRM_FL | EXT4_COMPR_FL |\
>> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
>> index 765a482..e7d5ba2 100644
>> --- a/fs/ext4/extents.c
>> +++ b/fs/ext4/extents.c
>> @@ -3185,7 +3185,7 @@ int ext4_ext_get_blocks(handle_t *handle, struct inode *inode,
>> {
>> struct ext4_ext_path *path = NULL;
>> struct ext4_extent_header *eh;
>> - struct ext4_extent newex, *ex;
>> + struct ext4_extent newex, *ex, *last_ex;
>> ext4_fsblk_t newblock;
>> int err = 0, depth, ret, cache_type;
>> unsigned int allocated = 0;
>> @@ -3366,6 +3366,14 @@ int ext4_ext_get_blocks(handle_t *handle, struct inode *inode,
>> EXT4_STATE_DIO_UNWRITTEN;;
>> }
>> }
>> +
>> + if (unlikely(inode->i_flags & EXT4_EOFBLOCKS_FL)) {
>> + BUG_ON(!eh->eh_entries);
>
> Perhaps BUG_ON() is too strong? Maybe add some warning messages first.
perhaps ... not sure how we would get here w/ no entries.
...
>> @@ -5315,6 +5321,11 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr)
>> goto err_out;
>> }
>> }
>> + if ((inode->i_flags & EXT4_EOFBLOCKS_FL)) {
>> + rc = vmtruncate(inode, attr->ia_size);
>> + if (rc)
>> + goto err_out;
>> + }
>> }
>>
>
> I am a little lost why doing vmtruncate here...
Hm first off I assume vmtruncate will clear blocks past that size,
but tonight I'm not seeing how it gets there.
Anyway, it looks like any setting of the size, truncate up or down
(or to current size) will clear any blocks past EOF.
>> rc = inode_setattr(inode, attr);
>> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
>> index b63d193..71f578e 100644
>> --- a/fs/ext4/ioctl.c
>> +++ b/fs/ext4/ioctl.c
>> @@ -92,6 +92,16 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>> flags &= ~EXT4_EXTENTS_FL;
>> }
>>
>> + if (flags & EXT4_EOFBLOCKS_FL) {
>> + /* we don't support adding EOFBLOCKS flag */
>> + if (!(oldflags & EXT4_EOFBLOCKS_FL)) {
>> + err = -EOPNOTSUPP;
>> + goto flags_out;
>> + }
>> + } else if (oldflags & EXT4_EOFBLOCKS_FL)
>> + /* free the space reserved with fallocate KEEPSIZE */
>> + vmtruncate(inode, inode->i_size);
>> +
>> handle = ext4_journal_start(inode, 1);
>> if (IS_ERR(handle)) {
>> err = PTR_ERR(handle);
>
> And here...
Well here we are clearing the EOFBLOCKS flag so we'd want to clear any
blocks past EOF.... but now, does vmtruncate do that?
Ok, count me as confused too, but mostly jsut so far as how does
vmtruncate clear the blocks beyond eof. I guess I glossed over this when reading it.
-Eric
next prev parent reply other threads:[~2010-01-20 3:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 21:45 [PATCH] Add flag to files with blocks intentionally past EOF Eric Sandeen
2010-01-20 0:46 ` Mingming
2010-01-20 3:58 ` Eric Sandeen [this message]
2010-01-20 8:37 ` Andreas Dilger
2010-01-20 9:15 ` Aneesh Kumar K. V
2010-01-20 9:03 ` Aneesh Kumar K. V
2010-01-22 0:32 ` Andreas Dilger
2010-01-22 17:40 ` Eric Sandeen
2010-01-21 18:00 ` [PATCH V2] " Eric Sandeen
2010-01-21 20:32 ` Jiaying Zhang
2010-02-24 16:26 ` tytso
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=4B567F77.5030103@redhat.com \
--to=sandeen@redhat.com \
--cc=cmm@us.ibm.com \
--cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).