On Sat 10-02-07 23:44:01, OGAWA Hirofumi wrote:
> [RESEND: forget to add [email protected]]
>
> If the DIO write on FAT is expanding the size, it will be fail by -EINVAL,
> because FAT can't handle it now.
>
> This patch fallback it to the normal buffered-write and would return
> success.
>
> Signed-off-by: OGAWA Hirofumi <[email protected]>
Signed-off-by: Jan Kara <[email protected]>
Just to explain a bit: I think that returning EINVAL is quite unexpected
for users in this case (I actually got a bugreport which turned out to be
this problem) and fallback to buffered IO seems to be a reasonable thing to
do. Probably it's not the cleanest solution but for FAT I think it's good
enough ;).
Honza
> ---
>
> fs/fat/inode.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -puN fs/fat/inode.c~fat_direct-io-fallback fs/fat/inode.c
> --- linux-2.6/fs/fat/inode.c~fat_direct-io-fallback 2007-02-10 22:08:33.000000000 +0900
> +++ linux-2.6-hirofumi/fs/fat/inode.c 2007-02-10 22:08:33.000000000 +0900
> @@ -173,10 +173,12 @@ static ssize_t fat_direct_IO(int rw, str
> *
> * But we must fill the remaining area or hole by nul for
> * updating ->mmu_private.
> + *
> + * Return 0, and fallback to normal buffered write.
> */
> loff_t size = offset + iov_length(iov, nr_segs);
> if (MSDOS_I(inode)->mmu_private < size)
> - return -EINVAL;
> + return 0;
> }
>
> /*
> _
--
Jan Kara <[email protected]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
