Denis Karpov <ext-denis.2.karpov@xxxxxxxxx> writes: > I realise that, but in this particular case I deal with non-critical data > on a large FAT partition and can probably afford certain risk of damaging > the data. What I can't afford is to spend several minutes fsck'ing huge FAT > partition on slow SD/MMC media during bootup. > > So I choose to optionally receive notification of errors encountered > during 'run time' and act upon them. > > Otherwise, nothing stops you from doing proper fsck before mounting. I think fsckless is to add the reliability to fs driver (logging, softupdate, etc.). Yes, it's not easy, and it needs time. Anyway, I actually thought about softupdate (and some others) before, I think it's _not_ nothing. > IMO, receivng notification of errors is benefitial in any case: > together with the 1st patch above it gives full flexibility to user space > to implement fs 'run-time' errors handling policy (at least for FAT,EXT2), > e.g.: > > - do nothing: remount r/o on errors, don't monitor kernel notifications (old/default > behavior) > - remount-ro on errors, get notified; unmount partition, fsck, mount > partition back r/w; > - ignore errors (continue), get notified: unmount the partition later at > suitable time, fsck, mount back r/w If this is monitoring interface, I guess it should be more generic. And I guess it will tell what happened in kernel, not fs_clean. (There is no guarantee about fs state) If not, some errors can not be detected by fs driver. User may know some run-time errors by fs_clean, but some run-time errors is not. So, user can not trust fs_clean. 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
