Christoph Hellwig <hch@xxxxxx> writes: > Commit ae78bf9c4f5fde3c67e2829505f195d7347ce3e4 added a -o flush > option to the fat driver back in 2006, which causes asynchronous > writeout after I/O operations ASAP. This already is quite hacky > and not something I like very much, but even worse the option > is accepted when using the more common vfat filesysten type, but > only actually implemented for the less common legacy msdos > filesystem type. > > This tells us two lessons: > > - the -o flush option probably never got a whole lot of exposure > and users didn't notice it doesn't work. We might as well just > remove it again Sigh. Chris, could you handle this? > - having the highlevel inode operations duplicated between msdos > and vfat is probably a bad idea, and we should only branch out > for the very low-level directory entry manipulations. I know you are finding the reason to merge those. ;) Well, what code are you suggesting? (BTW, this is not meaning "Please send a patch."). Can we do it without the user visible change? And if it has the user visible change, what is benefit to users? I know, if we kill original design decision with the user visible change, we can write much more faster/cleaner code. (e.g. some I/O can be reduced for directory. etc.) But, for fatfs, I'm thinking there is no benefit to take a pain by the user visible change, at least for now. 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