Hi,
OGAWA Hirofumi wrote:
Hiroyuki Machida <[email protected]> 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 <[email protected]>, 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 <[email protected]>, I mentioned about this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |