kernel.git/fs/ext3/inode.c, branch linux-2.6.20.y

revert "retries in ext3_prepare_write() violate ordering requirements"

2007-04-13T20:47:18Z

Revert e92a4d595b464c4aae64be39ca61a9ffe9c8b278. Dmitry points out "When we block_prepare_write() failed while ext3_prepare_write() we jump to "failure" label and call ext3_prepare_failure() witch search last mapped bh and invoke commit_write untill it. This is wrong!! because some bh from begining to the last mapped bh may be not uptodate. As a result we commit to disk not uptodate page content witch contains garbage from previous usage." and "Unexpected file size increasing." Call trace the same as it was in first issue but result is different. For example we have file with i_size is zero. we want write two blocks , but fs has only one free block. ->ext3_prepare_write(...from == 0, to == 2048) retry: ->block_prepare_write() == -ENOSPC# we failed but allocated one block here. ->ext3_prepare_failure() ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :) if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries)) goto retry; Finally when all retries will be spended ext3_prepare_failure return -ENOSPC, but i_size was increased and later block trimm procedures can't help here. We don't appear to have the horsepower to fix these issues, so let's put things back the way they were for now. Cc: Kirill Korotaev Cc: Ingo Molnar Cc: Ken Chen Cc: Andrey Savochkin Cc: Cc: Dmitriy Monakhov Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

[PATCH] retries in ext3_prepare_write() violate ordering requirements

2006-12-07T16:39:37Z

In journal=ordered or journal=data mode retry in ext3_prepare_write() breaks the requirements of journaling of data with respect to metadata. The fix is to call commit_write to commit allocated zero blocks before retry. Signed-off-by: Kirill Korotaev Cc: Ingo Molnar Cc: Ken Chen Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3: make meta data reads use READ_META

2006-09-30T18:29:42Z

Signed-off-by: Jens Axboe

[PATCH] inode-diet: Eliminate i_blksize from the inode structure

2006-09-27T15:26:18Z

This eliminates the i_blksize field from struct inode. Filesystems that want to provide a per-inode st_blksize can do so by providing their own getattr routine instead of using the generic_fillattr() function. Note that some filesystems were providing pretty much random (and incorrect) values for i_blksize. [bunk@stusta.de: cleanup] [akpm@osdl.org: generic_fillattr() fix] Signed-off-by: "Theodore Ts'o" Signed-off-by: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3: More whitespace cleanups

2006-09-27T15:26:10Z

More white space cleanups in preparation of cloning ext4 from ext3. Removing spaces that precede a tab. Signed-off-by: Dave Kleikamp Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3: inode numbers are unsigned long

2006-09-27T15:26:09Z

This is primarily format string fixes, with changes to ialloc.c where large inode counts could overflow, and also pass around journal_inum as an unsigned long, just to be pedantic about it.... Signed-off-by: Eric Sandeen Cc: Mingming Cao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3 and jbd cleanup: remove whitespace

2006-09-27T15:26:09Z

Remove whitespace from ext3 and jbd, before we clone ext4. Signed-off-by: Mingming Cao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3 sequential read regression fix

2006-09-16T19:54:32Z

ext3-get-blocks support caused ~20% degrade in Sequential read performance (tiobench). Problem is with marking the buffer boundary so IO can be submitted right away. Here is the patch to fix it. 2.6.18-rc6: ----------- # ./iotest 1048576+0 records in 1048576+0 records out 4294967296 bytes (4.3 GB) copied, 75.2726 seconds, 57.1 MB/s real 1m15.285s user 0m0.276s sys 0m3.884s 2.6.18-rc6 + fix: ----------------- [root@elm3a241 ~]# ./iotest 1048576+0 records in 1048576+0 records out 4294967296 bytes (4.3 GB) copied, 62.9356 seconds, 68.2 MB/s The boundary block check in ext3_get_blocks_handle needs to be adjusted against the count of blocks mapped in this call, now that it can map more than one block. Signed-off-by: Suparna Bhattacharya Tested-by: Badari Pulavarty Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3_getblk() should handle HOLE correctly

2006-09-08T17:22:50Z

It has been reported that ext3_getblk() is not doing the right thing and triggering following WARN(): BUG: warning at fs/ext3/inode.c:1016/ext3_getblk() ext3_getblk+0x98/0x2a6 md_wakeup_thread+0x26/0x2a ext3_bread+0x1f/0x88 ext3_quota_read+0x136/0x1ae v1_read_dqblk+0x61/0xac dquot_acquire+0xf6/0x107 ext3_acquire_dquot+0x46/0x68 dqget+0x155/0x1e7 dquot_transfer+0x3e0/0x3e9 dput+0x23/0x13e ext3_setattr+0xc3/0x240 current_fs_time+0x52/0x6a notify_change+0x2bd/0x30d chown_common+0x9c/0xc5 strncpy_from_user+0x3b/0x68 do_path_lookup+0xdf/0x266 __user_walk_fd+0x44/0x5a sys_chown+0x4a/0x55 vfs_write+0xe7/0x13c sys_mkdir+0x1f/0x23 syscall_call+0x7/0xb Looking at the code, it looks like it's not handle HOLE correctly. It ends up returning -EIO. Here is the patch to fix it. If we really want to be paranoid, we can allow return values 0 (HOLE), 1 (we asked for one block) and return -EIO for more than 1 block. But I really don't see a reason for doing it - all we need is the block# here. (doesn't matter how many blocks are mapped). ext3_get_blocks_handle() returns number of blocks it mapped. It returns 0 in case of HOLE. ext3_getblk() should handle HOLE properly (currently its dumping warning stack and returning -EIO). Signed-off-by: Badari Pulavarty Acked-by: Mingming Cao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] ext3 -nobh option causes oops

2006-07-31T20:28:44Z

For files other than IFREG, nobh option doesn't make sense. Modifications to them are journalled and needs buffer heads to do that. Without this patch, we get kernel oops in page_buffers(). Signed-off-by: Badari Pulavarty Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds