[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090405032211.GH7553@mit.edu>
Date: Sat, 4 Apr 2009 23:22:11 -0400
From: Theodore Tso <tytso@....edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc: linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH 2/2] [PATCH] ext4: truncate the file properly if we
fail to copy data from userspace.
On Tue, Mar 31, 2009 at 02:59:26PM +0530, Aneesh Kumar K.V wrote:
> In generic_perform_write if we fail to copy the user data we don't
> update the inode->i_size. We should truncate the file in the above case
> so that we don't have blocks allocated outside inode->i_size. Add
> the inode to orphan list in the same transaction as block allocation
> This ensures that if we crash in between the recovery would do the truncate.
Same problem as my comment in for the last patch; it seems rather
dangerous to try to call ext4_orphan_add() outside of ext4_truncate().
Can we instead call vmtruncate() inside the same transaction handle?
i.e., figure out how many journal credits will be needed for the
potential truncate, and add it to number of credits to reserve for the
begin_write and/or write_end handle, and then call vmtruncate before
calling ext4_journal_stop(). Can anyone see a problem with this
approach?
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists