Re: [RFD] FAT robustness

[Hiroyuki Machida]

Hi,

OGAWA Hirofumi wrote:
> Hiroyuki Machida <machida@xxxxxxxxxxxxx> writes:
>
>
> > We currently plan to add following features to address FAT corruption.
> >
> >    - Utilize standard 2.6 features as much as possible
> > 	- Implement as options of fat, vfat and uvfat
>
>
> What is the uvfat? typo (xvfat)?  Why is this an option (does it have
> the big demerit)?

uvfat is another variant of vfat, like umsdos.
Xvfat for 2.4 has following directories and file organization;
	most files are located at fs/xvfat.
	and most of them, copied from fs/fat and fs/vfat and renamed
	to have prefix like 'xvfat_'.
For 2.6, I feel that the above organization need to be changed.
And xvfat for 2.4 had some performance degradation. So I guess 'option'
is better.

> > 	- Utilize noop elevator to cancel unexpected operation reordering
>
>
> Why don't you use the barrier?

You mean that using requests with barrier flag is enough and there is
no reason to specify IO-sched ?

It is better to preserve order of updating data, some circumstance
like appending data. 

At xvfat for 2.4 had own elevator function, to preserve EraseBlock unit
ordering for memory card device. 

To begin consideration for 2.6, I'd like to make it simple. But later
we need to address to this issue. So I thought at first using "noop",
later switch special elevator function to handle device better.


> >    - Coordinate order of operations so that update data first, meta
> > 	 data later with transaction control
>
>
> Is this meaning the SoftUpdates? What does this guarantee? How does
> this handle the rename(), and cyclic dependency of updates?

In <42DE91E7.2060603@xxxxxxxxxxxxx>, I mentioned about this.

> >    - With O_SYNC, close() make flush all related data and
> > 	 meta-data, then wait completion of I/O
>
>
> What is this meaning? Why does O_SYNC only flush at close()?

> From application's point of view, application wants to believe 
close()ed file is correctly written, without any corruption.

At least close() need to guarantee this. It's ok every write()
flush meta data and data and wait compeletion I/O.

At least fat on 2.4.20, VFS sync inode on write() with O_SYNC,
however it don't take care about super block. At FAT side 
don't care about O_SYNC. That's problem.


> Almost things in your email is needing the detail.

> I'm thinking the SoftUpdates is best solution for now. Could you tell
> the detail of your solution?

In <42DE91E7.2060603@xxxxxxxxxxxxx>, I mentioned about this.

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