2013/9/24, OGAWA Hirofumi :
> Namjae Jeon writes:
>
We considered after your advice before. we reach for the conclusion
that use this method.
because, Cluster is already allocated in fat fallocate and
when we write with radom offset over i_size on fallocated region, It
wil
Namjae Jeon writes:
>>> We considered after your advice before. we reach for the conclusion
>>> that use this method.
>>> because, Cluster is already allocated in fat fallocate and
>>> when we write with radom offset over i_size on fallocated region, It
>>> will be hit by fat cache in fat_bmap of
2013/9/23, OGAWA Hirofumi :
> Namjae Jeon writes:
>
+ if (MSDOS_I(inode)->mmu_private > round_up(i_size, sb->s_blocksize)
+ && pos > i_size) {
+ err = fat_zero_falloc_area(file, mapping, pos);
+ if (err) {
+ fat_msg(sb,
Namjae Jeon writes:
>>> + if (MSDOS_I(inode)->mmu_private > round_up(i_size, sb->s_blocksize)
>>> + && pos > i_size) {
>>> + err = fat_zero_falloc_area(file, mapping, pos);
>>> + if (err) {
>>> + fat_msg(sb, KERN_ERR,
>>> +
2013/9/21, OGAWA Hirofumi :
> Namjae Jeon writes:
Hi OGAWA.
>
> Entirely, we would have to consider in the case of write fail
> (e.g. -ENOSPC). If write failed, it will call truncate(). Then, it can
> be truncate the fallocate region too unexpectedly.
I agree. I will update as your suggestion.
>
Namjae Jeon writes:
Entirely, we would have to consider in the case of write fail
(e.g. -ENOSPC). If write failed, it will call truncate(). Then, it can
be truncate the fallocate region too unexpectedly.
> + if (!create) {
> + /*
> + * to map
From: Namjae Jeon
v6: In v3 of the patch we released the allocated clutsers in
fat_file_release on the basis of d_count. Moving this from fat_file_release
to fat_evict_inode and on the basis of i_count , so that allocated
clusters are released at the last refrence of the inode when inode
evicts f
7 matches
Mail list logo
