Hi,
I need to explain background information more. My descriptions tends
to be depend on some knowledge about current xvfat for 2.4 kernel.
I'm not a author of xvfat fo 2.4 kernel, but can explain little more.
Current xvfat for 2.4 is designed to some specific flash memory card
controller which can guarantee atomicity of operation on ERASE-BLOCK size
unit. Xvfat for 2.4 try to merge operations on same ERASE-BLOCK under
some ordering constrain.
And xvfat for 2.4 uses own version of transaction control using
in-core memory, not storage device like HDD nor flash ram,
to accomplish the above goal, with minimal changes on existing
FAT implementation. And this transaction control let FAT operations
came from different threads to fee from mixed up, where potentially
operation ordering problems would be caused.
We'll start with HDD, however later we'll cover memory devices.
For memory devices we may prepare another elevator functions,
depending on property of devices or lower layer. E.g. NAND/AND
flash have different operation units for read/write and erase,
and have some translation layer.
Paulo Marques wrote:
Hiroyuki Machida wrote:
[...]
Q3 : I'm not sure JBD can be used for FAT improvements. Do you
have any comments ?
I might not be the best person to answer this, but this just seems so
obvious:
Any comments are welcome.
If you plan to let a recently hot-unplugged device to be used in another
OS that doesn't understand your journaling extensions, your disk will be
corrupted.
If this is supposed to work only on OS's that understand your journaling
extensions, then there are much better filesystems out there with
journaling already.
I agree. Even not removable media, this situation will be occurred.
Suppose that device like audio player which acts as USB client and provide
USB Mass class target class. Embedded storage may be handled through by
USB Host side, like Win PC or Mac.
You might be able to reduce the size of the time window where hot
removing the media will cause problems, like writting all the data first
and update the metadata in as few operations as possible. But that just
reduces the probability of data corruption. It doesn't eliminate it at all.
As other messages said, some developers suggest "SoftUpdate" to be used.
I need to consider about situation where memory devices are used, not HDD.
-
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/
