Re: vfat vs msdos and -o flush

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Hellwig <hch@xxxxxx> writes:

> There's a couple of things I have in mind:
>
>  - first move fat and msdos into the same module to make integration
>    easier.  Keep MODULE_ALIASes for vfat and msdos to allow old module
>    (auto-)load setups working.  Move the setup for the two
>    file_system_type structures to super.c
>  - look at the spurious differences between namei_msdos.c and
>    namei_vfat.c.  Here's a few I've noticed and I'll have patches for
>    soon hopefully:
>
>      - msdos only updates c and mtime in msdos_add_entry, but vfat
>        also updates atime
>      - msdos only updates ctime in rmdir and unlink , vfat otoh only
>        updates mtime and atime
>      - vfat updates the ctime on the new inode in rename, msdos
>        doesn't.

Originally msdos didn't have atime field, so atime is intended more or
less. Others are I'm not pretty sure, so, didn't touch original
one. However, I have no objection to others.

>   - udate i_version consistently in msdos, too (probably not needed
>     without nfs exporting, but just to make the code similar)

Yes, nfs export of msdos would be totally broken (although vfat is also
broken more or less due to stable ino issue). However, it sounds good.

>   - unify the vfat_add_entry/msdos_add_entry prototypes and make them
>     function pointers hanging off the superblock information
>   - move the hidden file handling and msdos_format_name into a helper
>     and make that a function pointer hanging off the superblock,
>     with a no-op implementation for vfat
>   - unify the prototypes of msdos_find and vfat_find and make it
>     a function pointer hanging off the superblock
>
> At this point basically all the inode operations are the same for
> both and can be merged, spreading out via the three operations
> mentioned above.  If we don't want the indirection it could also
> be done using if/else statements in a small helper.  The only one
> I haven't analyzed in detail yet is rename, because it looks too
> different and will need some refactoring first.

I think this is meaning to add top level layer using existent dentry
handling basically. After all, we would have to care those original
strange difference (sigh) in internal though, however this sounds good
to me.

[BTW, I was thinking in past, just kill msdos and adds new shortname
only option to vfat. ;)]

Thanks.
-- 
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux