Re: [PATCH 0/5] FAT errors, user space notifications

[OGAWA Hirofumi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/