Sony Beefs up FAT for Consumer Devices

An anonymous reader points to a report at LinuxDevices which says that "Sony has created an enhanced version of the vFAT filesystem that it says works better in Linux-based consumer electronic devices with removable USB mass storage devices. Unlike vFAT, the xvFAT filesystem will not induce a kernel panic if a USB storage device is removed during a write operation, Sony says," and writes "For now, xvFAT is a patch to the Linux 2.4.20 source tree maintained by CELF, an industry group of consumer electronics giants working to improve Linux for CE devices. Sony intends to submit the filesystem for inclusion in the mainstream 2.6 Linux tree as well."

Comments

Who to believe

[superpulpsicle]

You can believe Sony marketing that vFAT is truely more enhanced for electronic devices.

You can believe Sony doesn't want to pay M$ for using FAT. Therefore finding a need to innovate alittle.

You can believe Sony will probably not go very far with yet "another" standard it created.

The choice is yours...

How many...

[Creepy Crawler]

Write operations does it do to the file allocation table when a decently sized file is copied?

Whats the average throughput compared to a baseline of linearly read data?

Could it be used on CD's and the like instead of iso9660fs and have the main OSes capable of reading them?

Whats the CPU% used for reading 1 MB sequential data per second?

Whats the license (if dual licensed or such) and are there any SOny patents that they might try to stifle this later?

Why cant you prevent Panics from removing vFat utilizing devices? Shouldnt have Linux came up with a way to gracefully determine 'dirtiness' and then dump the kmod gracefully?

I know some questions sound paranoid, but this is Sony we're dealing with. UMD, mem-stick, and god knows how many other things they've encumbered with crap and DRM have proved them one way. This proves them slightly the other....

Very weird company. Hurt with one hand, heal with the other.

Re:How many...

[TopSpin]

Creepy Crawler:
Why cant you prevent Panics from removing vFat utilizing devices? Shouldnt have Linux came up with a way to gracefully determine 'dirtiness' and then dump the kmod gracefully?

Foolhardy:
What does the filesystem have to do with crashing, other than the quaility of the driver? i.e. what do the on-disk file structures have to do with having a kernel panic?

Good questions. You've just stumbled into a significant flaw in *nix generally.

Linux, begotten of Unix, does not subscribe to the notion of transient filesystems. Behavior is undefined when filesystems vanish suddenly. It seems obvious enough; the kernel should block IO activity, flush buffers, unmount and return errors to users that are attempting IO to the now missing filesystem. Whatever "damage" occurs to the data (as opposed to filesystem metadata) is, rightly, the users problem. Unfortunately, this is not what happens.

What does happen falls under the euphemism "implementation defined." A good example is evident with NFS; *nix admins have been independently discovering this for years. If an NFS mount vanishes, *nix processes often hang indefinitely with no means of recovery. Various "soft mount" hacks appeared to accommodate the real world where network problems exist. Again, the actual behavior is not consistent; "soft mounts" are not always honored and obscure things like NFS versions or various "modes" of IO factor into why or why not.

I believe that in the early days the need to optimize IO led to designs that made no allowance for transient filesystems. This design propagated itself into POSIX, where behavior was left undefined. Even today you find crazy things like kernel panics when a FAT filesystem does something other than remain perpetually mounted. There is no "correct" thing to do and developers, hesitant to start inventing policy where none exists, go on being oblivious to the problem.

The fact is that a large percentage of "important" filesystems are transient. Remote storage, removable storage, etc. host valuable data, while permanently attached storage provides only basic machinery.

Sony, stuck trying to make transient vFAT filesystem hosting devices play nice with Linux, has stepped in and attempted to address the problem. *nix will be dragged kicking and screaming into the modern era of transient filesystems. Unfortunately, Sony's pragmatic, special case solution does nothing to address the larger problem, and whatever solutions emerge for all the other possible cases probably will be/are inconsistent in both implementation and behavior.

Blame the *nix folks who, 30 years ago, failed to anticipate hot pluggable keychains with hundreds of megabytes of storage.

Crash???

[Foolhardy]

Unlike vFAT, the xvFAT filesystem will not induce a kernel panic if a USB storage device is removed during a write operation, ...

The kernel normally crashes when you yank a block device on a USB bus that uses vFAT?
The FS can't just fail the pending write operations? It has to kill the kernel?

What does the filesystem have to do with crashing, other than the quaility of the driver? i.e. what do the on-disk file structures have to do with having a kernel panic?

I mean, that's what xvFAT is, a different set of disk structures, isn't it? (not just a different driver)
There's really no way to make the current vFAT driver recover safely with the current FAT disk structures?

Re:Wow, Sony just gained major cool points for tha

[Directrix1]

Here is a ext2fs driver for windows. Not currently the most top of the line file system for Linux, but still a pretty nice addition (you know if you like dual boot and don't want your partition to have any security respected on it :-P).