On Thu 2009-06-04 08:57:58, Artem Bityutskiy wrote: > Andrew Morton wrote: >> hm, I'm uncertain on the desirability or otherwise of the overall feature. >> >> Are there users or distros or device manufacturers asking for this? >> Where did the requirement come from? >> >> What downstream application will handle the uevent messages? Do you >> have some userspace design/plan in mind? >> >> IOW, it would be useful if we were told more about all of this, rather >> than just staring at a kernel patch! > > As the original idea came from me, while whole implementation > and design was done by Denis, I'll comment on this. > > Our use-case is about hand-held devices. We are particularly > working with large FAT volumes on MMC. Do not question please > why it is FAT and not something else :-) Anyway, FAT is very > unreliable, and often hits errors, in which case it simply > switches to read-only mode, and usually prints something to > the printk ring buffer. So fsck the mmc card on card insertion...? fsck.vfat on flash is pretty fast operation (as it onl needs to read directories + FATs). Android 1.5 implements this. ...otherwise you will loose data on two files sharing clusters, will never recover lost clusters, etc. Perhaps it would be feasible to permit read-only mount of unclean VFAT, run fsck in background, and buffer any changes in memory until fsck finishes? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
