André Braga wrote:
If the FS itself provides a thread for syncing data (which is weirs as it should be handled by the VFS in my humble opinion, than it fits with my definition of how it should be done.No, no, no. Not the VFS. Either you take in account the particulars of every storage medium (like flash memory) and end up with a VERY swollen VFS layer, or you put the burden on the file system itself, which should be tailored for the medium in question.
That does not make sense at all. I can format a flash media, for instance, with any FS I want. So you are suggesting every possible FS must be aware of flash devices? If so, then it is yet another point for it being the the VFS layer and not the FS itself.
In any case, what the thread would do is simply call the sync() function with will be implemented by each FS as they need it to.
Again, this is not FS dependent. This is media dependent. Again, In OSs like Haiku I can format any media with any FS I want (as long as there is enough space on that media to hold the FS structures.Cases in point: JFFS, NFS etc. Syncing and not taking into account the characteristics of the medium would a) wear out flash memory very quickly; b) generate a trickle of network traffic which sometimes is just not acceptable.
Not to mention locking issues and atomicity when dealing with networked filesystems...
Andre, again this makes no sense. The sync thread (or whatever it would be) would just call sync() for each read-write filesystem.
IMEHO the VFS layer should be thin and flexible, and the burden of gory details should be on the FS layer itself. IMEHO(2) no amount of parametrization and callbacks came make up for wrong design, even if that means going against the canon of historical "wisdom" and established practices =) Still IMEHO, of course.
So, in your opinion, if we have a feature that is used by all filesystems on earth we should implement it again and again in each filesystem instead of the VFS layer? Well, you are wrong.
-Bruno
