| Message ID | 20091208110043.GC4095@quack.suse.de |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Jan Kara <jack@suse.cz> writes: > Hi Ted, > > do you plan on merging my fixes for writev filesystem corruption and > 64-bit quota patches? The writev patch is independent of any other patch > and should go in ASAP, 64-bit quota patch depends on generic quota code BTW, where can I find this changes for generic quota code. Your linux-quota-2.6.git disappeared from kernel.org couple weeks ago, so I can't find in anywhere. > change so either I can merge it or you can merge a bit later (it's a small > change for ext4). > The patches were sent as: > http://marc.info/?l=linux-ext4&m=125978147226649&w=3 > (writev corruption fix - it has a minor whitespace bug so I'm attaching a > version with that bug fixed) > http://marc.info/?l=linux-ext4&m=125978717902673&w=3 > (64-bit quota support) > > > Honza -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 08, 2009 at 12:00:43PM +0100, Jan Kara wrote: > Hi Ted, > > do you plan on merging my fixes for writev filesystem corruption and > 64-bit quota patches? The writev patch is independent of any other patch > and should go in ASAP, 64-bit quota patch depends on generic quota code > change so either I can merge it or you can merge a bit later (it's a small > change for ext4). Why don't I take the writev patch, and let you merge the 64-bit quota patch along with the generic quota changes? Does that make sense? The only thing that worries me a tiny bit is that there are some quota bug fixes which the OpenVZ folks have submitted, that I need to review and haven't gotten to yet, and there's a chance they may conflict with your 64-bit ext4 quota changes. But I'm sure we can deal with any potential merge conflicts should they come up. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tue 08-12-09 20:03:09, Dmitry Monakhov wrote: > Jan Kara <jack@suse.cz> writes: > > Hi Ted, > > > > do you plan on merging my fixes for writev filesystem corruption and > > 64-bit quota patches? The writev patch is independent of any other patch > > and should go in ASAP, 64-bit quota patch depends on generic quota code > BTW, where can I find this changes for generic quota code. > Your linux-quota-2.6.git disappeared from kernel.org couple weeks ago, > so I can't find in anywhere. There's linux-fs-2.6.git which now carries also the quota changes (they are scarce enough that I've decided to merge quota tree into my linux-fs-2.6 tree). Honza -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 08-12-09 16:21:09, tytso@mit.edu wrote: > On Tue, Dec 08, 2009 at 12:00:43PM +0100, Jan Kara wrote: > > Hi Ted, > > > > do you plan on merging my fixes for writev filesystem corruption and > > 64-bit quota patches? The writev patch is independent of any other patch > > and should go in ASAP, 64-bit quota patch depends on generic quota code > > change so either I can merge it or you can merge a bit later (it's a small > > change for ext4). > > Why don't I take the writev patch, and let you merge the 64-bit quota > patch along with the generic quota changes? Does that make sense? Yes, fine for me. I just didn't want to merge ext4 quota changes without your approval. > The only thing that worries me a tiny bit is that there are some quota > bug fixes which the OpenVZ folks have submitted, that I need to review > and haven't gotten to yet, and there's a chance they may conflict with > your 64-bit ext4 quota changes. But I'm sure we can deal with any > potential merge conflicts should they come up. Yes, I need to take a look at those as well. So far they don't seem to be conflicting AFAICS. Honza
From 8bd74d5ced949f276e51d770092bff576d42fa79 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Wed, 2 Dec 2009 20:05:23 +0100 Subject: [PATCH 2/3] ext4: Fix data / filesystem corruption when write fails to copy data When ext4_write_begin fails after allocating some blocks or generic_perform_write fails to copy data to write, we truncate blocks already instantiated beyond i_size. Although these blocks were never inside i_size, we have to truncate pagecache of these blocks so that corresponding buffers get unmapped. Otherwise subsequent __block_prepare_write (called because we are retrying the write) will find the buffers mapped, not call ->get_block, and thus the page will be backed by already freed blocks leading to filesystem and data corruption. Signed-off-by: Jan Kara <jack@suse.cz> --- fs/ext4/inode.c | 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 2c8caa5..e802988 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1534,6 +1534,16 @@ static int do_journal_get_write_access(handle_t *handle, return ext4_journal_get_write_access(handle, bh); } +/* + * Truncate blocks that were not used by write. We have to truncate the + * pagecache as well so that corresponding buffers get properly unmapped. + */ +static void ext4_truncate_failed_write(struct inode *inode) +{ + truncate_inode_pages(inode->i_mapping, inode->i_size); + ext4_truncate(inode); +} + static int ext4_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata) @@ -1599,7 +1609,7 @@ retry: ext4_journal_stop(handle); if (pos + len > inode->i_size) { - ext4_truncate(inode); + ext4_truncate_failed_write(inode); /* * If truncate failed early the inode might * still be on the orphan list; we need to @@ -1709,7 +1719,7 @@ static int ext4_ordered_write_end(struct file *file, ret = ret2; if (pos + len > inode->i_size) { - ext4_truncate(inode); + ext4_truncate_failed_write(inode); /* * If truncate failed early the inode might still be * on the orphan list; we need to make sure the inode @@ -1751,7 +1761,7 @@ static int ext4_writeback_write_end(struct file *file, ret = ret2; if (pos + len > inode->i_size) { - ext4_truncate(inode); + ext4_truncate_failed_write(inode); /* * If truncate failed early the inode might still be * on the orphan list; we need to make sure the inode @@ -1814,7 +1824,7 @@ static int ext4_journalled_write_end(struct file *file, if (!ret) ret = ret2; if (pos + len > inode->i_size) { - ext4_truncate(inode); + ext4_truncate_failed_write(inode); /* * If truncate failed early the inode might still be * on the orphan list; we need to make sure the inode @@ -3091,7 +3101,7 @@ retry: * i_size_read because we hold i_mutex. */ if (pos + len > inode->i_size) - ext4_truncate(inode); + ext4_truncate_failed_write(inode); } if (ret == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries)) -- 1.6.4.2