Messages in this thread Patch in this message | | | Date | Sat, 21 Oct 2000 23:19:54 +0200 | From | Andries Brouwer <> | Subject | [PATCH] Re: 2.4.0-test10-pre3:mkdir() returns -EIO when ext2 filesystem full |
| |
On Sat, Oct 21, 2000 at 02:14:21PM +0100, Russell King wrote:
> Something weird is going on with VFS return codes with kernel > 2.4.0-test10-pre3: > > [root@sturm glibc-2.1.92]# df /var/tmp > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/hda3 127383 127383 0 100% /var > [root@sturm glibc-2.1.92]# mkdir /var/tmp/tst > mkdir: cannot create directory `/var/tmp/tst': Input/output error > > Just a guess, but I think this is caused by: > > dir_block = ext2_bread (inode, 0, 1, &err); > if (!dir_block) { > inode->i_nlink--; /* is this nlink == 0? */ > mark_inode_dirty(inode); > iput (inode); > return -EIO; > } > > in fs/ext2/namei.c:ext2_mkdir(). Note that I can't find any cases where > ext2_alloc_block() would actually give a ENOSPC return. > > Note (again) the dodgy return error by reference, and then we totally > ignore 'err', so even if ext2_alloc_block() was fixed, it wouldn't > matter unless this and probably other places were also fixed to return > err instead of EIO.
Ah, but I do find cases where we would get ENOSPC. So, the following patch, anticipated by you, fixes this.
diff -u --recursive --new-file ../linux-2.4.0test9/linux/fs/ext2/namei.c ./linux/fs/ext2/namei.c --- ../linux-2.4.0test9/linux/fs/ext2/namei.c Wed Sep 27 22:41:33 2000 +++ ./linux/fs/ext2/namei.c Sat Oct 21 22:59:59 2000 @@ -437,7 +437,7 @@ inode->i_nlink--; /* is this nlink == 0? */ mark_inode_dirty(inode); iput (inode); - return -EIO; + return err; } de = (struct ext2_dir_entry_2 *) dir_block->b_data; de->inode = cpu_to_le32(inode->i_ino); [if one is very cautious, return err ? err : -EIO would be safest, but I believe that all paths leading here in fact do set err]
Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |