Slashdot Mirror
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."
Like the summary explains, vfat (ie, fat) is used in all sorts of consumer electronic devices because it is (well, was) the most common filesystem for desktop users. Add to that, near ever desktop OS supports reading/writing fat and it's not much of a surprise that it'd be the common filesystem for ubiquity in data access on portable devices. The only other filesystem that'd make sense would be udf. But not every OS (read, Windows) readily supports that through usb, floppy, etc.
And if you wonder why they don't just use a data syncing program instead of exposing the filesystem itself to users, the simple answer is that it's much easier and desirable to the computer to just plug in a usb device anywhere and access it as a mass storage device than it is to have to install software everywhere for every device that you ever plan to connect to any computer you plan to use. Overall I like it this way since it means that if I'm willing to trade accessibility I can use whatever filesystem I please. But odds are I'll still use vfat because I really dislike the idea of not being able to access it wherever I go.
Eurohacker European paranoia, gun rights, and h
It would have been even cooler if they would have just used an already implemented open source file system and then wrote a driver for the Windows guys
Except the installable file system layer in Windows 2000 and XP has a reputation for being poorly documented. The file system headers also cost money, though an order of magnitude less than it cost in the Win2k era. Sony could pay this, but this expense is why you don't see an IFS port of Ext3, Reiser4, or any of the other popular Free file systems.
vfat is the greatest common denominator of file systems.
The number of filesystems Windows supports is pathetic, because it boils down to FAT32, NTFS, ISO9660, and SMB/CIFS. Your options are really quite limited.
The FAT patent was invalidated.
It's a mount option -- in the case of data corruption, it's usually safer to go down instantly rather than continue. However, I don't expect anyone but the worst lunatics to set it on a FAT filesystem, especially one on an USB device.
Having the kernel crash (as opposed to a panic) due to a bug in a filesystem driver is another story. I've once discovered that a maliciously malformed filesystem can send everything into the la-la land. This is where Hurd's separation of kernel structures would be useful.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
I'm gonna give it a shot.
Right now I'm going to start copying a large file to my thumb drive, and once it's got 30-40mb done, I'm going to pull out.
Wait for it!
Good news, everyone! All I got was an error message from GNOME -- "I/O Error while copying file foo.avi. Would you like to continue? Skip/Cancel/Retry"
I'm gonna stick the drive back in and tell it to continue -- stay tuned!
Holy crap, it picked up all on its own.
Wait...
Yep, it just passed an fsck.Sony, what are you smoking???
Something like ReiserFS doesn't scale well at the low end. On a 128M memory stick [iirc] the file system takes something like 16-20MB off the top. That's 15% of the drive gone instantly [compared to the 5M that FAT takes].
Granted if you have a 1GB memory stick the 20M or so that Reiser takes is less of a pain and the gains you get from the stability are more worth it...
Tom
Someday, I'll have a real sig.
On Windows 2000 or later, there is a special PNP IRP that is sent to devices that have been yanked: IRP_MN_SURPRISE_REMOVAL. All removable devices must support this IRP and it must succeed. Devices are to release any resources used by the device, fail all pending and future operations on the device (other than close/cleanup) and await a IRP_MN_REMOVE_DEVICE once all handles have been closed for final cleanup. This IRP is generally handled by the volume device, below the filesystem. The devices, including the filesystem, play dead until all handles are closed.
I pulled a USB flash drive while Explorer was copying a file to it. Explorer immediately gave me an ugly dialog box about not being able to find the file path with no option to retry or continue. I'm not sure what happens with memory-mapped file IO, but I know that when a pagefile becomes inaccessible, any thread that hits a hard fault hangs.
Paging files aren't supposed to be located on removable devices, because pagefiles can't be closed at runtime. Besides, the kernel would die with a KERNEL_DATA_INPAGE_ERROR if it couldn't retrieve a kernel page from a removed disk.
2000 enables write caching on removable devices by default, requiring you to use the "Safe hardware removal" applet. Microsoft found that too many people were simply yanking the things, so they made write caching disabled by default on XP. You can change the status of write caching on any volume in hardware->properties->policies.
It is safe to pull an idle device without using safe removal when write caching is disabled.