Re: [PATCH] let fat handle MS_SYNCHRONOUS flag

[Bernd Eckenfels]

In article <87pt237se1.fsf@xxxxxxxxxxxxxxxxxxx> you wrote:
> Current fatfs is not keeping the consistency of data on the disk at
> all.  So, after all, the data on a disk is corrupting until all
> syscalls finish, right?

Me thinks, fat is pretty robust, and with the small window it improves,
because most users will wait until the operation finished and unplug then.
Which is enough delay for scheduled sync, but not for delayed flushed blocks.

> If so, isn't this too slow? I doubt this is good solution for this
> problem (USB key unplugging)...

Hmm... Actually a "better" solution which involves a journalling filesystem
is not an option for most fat users becaue they need the interoperability.

So the only real solutions you have (beside educating the user to wait for
sync) is to make the corruption window smaller and perhaps do some
reordering on meta data changed to lower the dangers of corruptions.

> Well, it seems good as start of sync-mode though.

You mean, to build sync writes at the right places in the fatfs? I guess yes
that would be even better, so you have kind of soft updates for fat :)
However dont know how reliable the flash controllers are with reordering (if
they are somewhat smart)

How about having configurable sync intervalls per fs/device and default them
to 0 for removeable media?

Greetings
Bernd
-
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/