Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Data Storage Software Linux

Sony Beefs up FAT for Consumer Devices 56

Posted by timothy from the but-it's-all-muscle dept.
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."
This discussion has been archived. No new comments can be posted.

Sony Beefs up FAT for Consumer Devices More

Sony Beefs up FAT for Consumer Devices

Comments Filter:

  • Still won't buy Sony products. (Score:3, Insightful)

    by matria ( 157464 ) on Tuesday June 07, 2005 @12:19AM (#12743931)
    This is the same company that sues DVD decryption software authors, sues restaurant owners who's name happens to be Sony, sues people using old Sony cases for iPod mods.

    So apparently it's OK to "vigorously defend their IP", while blatantly violating everybody else's. I wonder if the same big bucks and lawyers that force little people to bow to their corporate steamroller had anything to do with voiding Microsoft's patent of the FAT filesystem?

    Don't misunderstand me; pulling out that particular stupid patent after all these years was a dirty stunt, and certainly deserved to get shot down, but that doesn't make Sony any cleaner. Two rabid pit bulls aren't any better than one.
    • So apparently it's OK to "vigorously defend their IP", while blatantly violating everybody else's.

      Whose IP is Sony "violating"? FAT is not patented or protected in any other way.

      I don't like Sony, but please don't try to create non-existent intellectual property out of thin air. The more people like you pay lip service to that nonsense, the more people will believe that it actually exists.
    • Oh come now... xvFAT is amazing it will- - optimize seamless communities - generate vertical e-services - everage synergistic convergence and best of all - engage e-business content Perfect solution

  • Who to believe (Score:3, Interesting)

    by superpulpsicle ( 533373 ) on Tuesday June 07, 2005 @12:20AM (#12743936)
    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... (Score:3, Interesting)

    by Creepy Crawler ( 680178 ) on Tuesday June 07, 2005 @12:27AM (#12743963)
    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... (Score:5, Interesting)

      by TopSpin ( 753 ) * on Tuesday June 07, 2005 @03:02AM (#12744571) Journal
      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.

      • Re:How many... (Score:5, Insightful)

        by david.given ( 6740 ) <dg@cowlark.com> on Tuesday June 07, 2005 @04:50AM (#12744888) Homepage Journal
        You've just stumbled into a significant flaw in *nix generally.

        Everything you've said here is correct, and I agree with you, but you haven't mentioned the fact that in general, dealing with transient filesystems is an enormously hard problem on any real OS. There is no quick fix for this.

        The problem is that you have to make sure that the filesystem on disk is consistent when the media is removed --- but by the time you know that the media is being removed, it's too late to do anything!

        Unix deals with this problem by simply refusing to deal with it: it requires you to dismount all filesystems before disconnecting the media. Which is fine if you're dealing with hard disks, but less fine on USB devices and floppies. (There's a good reason why most serious Unix hardware have software floppy drive eject mechanisms.)

        (Unix has the particularly unpleasant issue of the unified VM and I/O system; what do you do if you want to page in a block from a file system that's gone away? Seg fault? Block until it comes back again? Wave your arms in the air and run around in small circles? Different implementations do all three...)

        Windows and DOS attempt to deal with the problem by using write-through cacheing on anything it thinks is transient. This kills performance. (Try switching off write-through cacheing on your floppy disk sometime.) But even Windows wants you to dismount USB devices before removing them.

        Even CP/M had a variation of this problem --- there were specific system calls to detect disk changes and discard its caches. You were supposed to call this every time your program stopped for user input. Not all programs did, which meant that if you changed disks at the wrong time, you could end up with a corrupted disk...

        • Making sure the kernel structures themselves (which aren't going anywhere) remain consistent is sufficient to avoid a kernel panic - and to avoid most any problems (except the more-or-less unsolvable one of lost work) with the NFS issue mentioned above (assuming the host at the other end is taking care of its side)

          the problem with floppy disks and usb keys is that they allow you to "yank" them. i.e. there is a physical button on the floppy drive that will force the disk out of the drive, and the USB connec
        • Comment removed based on user account deletion

          • I think I remember reading about OSX having the ability to pull a usb device during write. It will give an error on screen, and then when you stick it back in it just continues the write... anyone else remember something like that?

            I can't comment on USB devices, but I've unplugged my iPod in the middle of write operations without a panic occurring. And yes, a dialog appears with a warning telling you not to do such things as it could cause data corruption.

            (tig)

        • I don't think you are addressing the parent's complaint.

          Of course if you pull the disk, the disk may be trashed. The complaint is that there is no real reason this should trash the rest of the system, as well as the disk.

          IMHO any reads/writes to a pulled disk should start returning errors at the moment the problem is detected (which may not be until it attempts to flush a block to the disk). The automount program could also get errors. I don't see why this is so hard to do. Most programs will gracefully h

        • Re:How many... (Score:3, Informative)

          by Foolhardy ( 664051 )
          On Windows 2000 or later, there is a special PNP IRP that is sent to devices that have been yanked: IRP_MN_SURPRISE_REMOVAL [microsoft.com]. 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 th
        • The problem is that you have to make sure that the filesystem on disk is consistent when the media is removed --- but by the time you know that the media is being removed, it's too late to do anything!

          There are two parts to the problem.

          1.) The robustness of the OS; does the OS account for the possibility of a device vanishing at some arbitrary moment?

          2.) The integrity of the filesystem; Is the possibility of metadata corruption permitted to exist?

          The answer to this first question is obviously no or Son
      • Linux, begotten of Unix, does not subscribe to the notion of transient filesystems. Behavior is undefined when filesystems vanish suddenly.

        I'm stunned.

        Unix was born on tape drives, not disk drives, and tapes are just as transient as USB thumb drives.

        (pause, remembering back to my days as a mainframe programmer)

        Ok, I take that back. The old IBM 9-track drives wouldn't drop the "window" until you dismounted the tape. That was to prevent you from accidentally removing a mounted tape. Hopefully the DEC
        • No, but tape drives and disk packs were mounted and unmounted by the operator, not by some random joe who yanks the power plug out whenever he gets somewhere he doesn't understand.
      • I believe that in the early days the need to optimize IO led to designs that made no allowance for transient filesystems.

        When Unix was created, there really weren't transient file systems. You had *removable* disks, but changing a disk pack wasn't as simple as yanking a dongle, you had to take the drive offline and spin it down and wait for the heads to retract before you could unmount it. Tapes and the like were handled differently (you did remember that 'tar' stands for Tape ARchiver, didn't you?), th
  • would you use fat at all if running linux? arn't there better alternatives that you don't have to pay for? (i'm assuming there are licensing costs for use of fat in consumer products)
      1. You use FAT because it's very well-supported,
        well-tested, and simple enough to not waste much
        space on small devices.
      2. As far as I know, there are no (known) patents
        covering it. As is mentioned in the article,
        Microsoft's recent attempt to patent it failed.
        Why would consumer devices be restricted, but not
        Linux?

    • Re:why... (Score:2, Informative)

      by 10101001 10101001 ( 732688 )
      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 the

    • Re:why... (Score:4, Informative)

      by bersl2 ( 689221 ) on Tuesday June 07, 2005 @01:40AM (#12744299) Journal
      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.

  • Crash??? (Score:4, Interesting)

    by Foolhardy ( 664051 ) <csmith32@gmai l . com> on Tuesday June 07, 2005 @01:07AM (#12744170)
    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:Crash??? (Score:5, Informative)

      by KiloByte ( 825081 ) on Tuesday June 07, 2005 @02:09AM (#12744403)
      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 [archive.org] 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 old umsdos driver was far easier to confuse.

        Just make a file with the same name as it's "special file", then 'ls' the directory.

        Bing! :)
  • But will you be able to cp stuff off that filesystem or is it write-only?

  • Sony Beef Fat? (Score:1, Funny)

    by Anonymous Coward
    Is this a delicious new foodstuff?
  • Nosy and Linux, Nosy and Linux.

    Good or bad? Nosy, Toshiba and IBM == cell processor, Nosy have sorted up a decent usb drive file system (not a memory-stick file system?).

    I hate the closed nature of Nosy's PSP, at least in 1.1 and above ;-) I do like the cell processor, and I want a cell laptop about 3 years ago.

    Still, big corporations taking an unhealthy interest in open source has proven mildly annoying in the past. IBM did a good job. SCO and Apple have pissed people off. Will Nosy play nice?

    *Nosy is
  • So, let me see if I understand this.

    They made a patch to implement their unique variant of vFAT to an old version of the old kernel and claim it's better.

    Great job, Sony.

  • I have to admit, I'm skeptical (Score:5, Informative)

    by croddy ( 659025 ) on Tuesday June 07, 2005 @04:39AM (#12744852)
    I'm skeptical that yanking a vfat-formatted usb-storage device out of the port while I'm in the middle of a write operation is going to cause a kernel panic.

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

  • Seeing as how vfat doesn't actually crash the kernel at all, this looks like total bullshit, unless they've fixed the 2GB file size limit or something. But even then, how is this better than EXT3 or ReiserFS? The only real Linux use for FAT is Windows compatibility, and this isn't going to be able to be very different from FAT32 at all if it's going to work with Windows.

    • Re:Vaporware (Score:3, Informative)

      by tomstdenis ( 446163 )
      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
  • Does this mean I'll be finding a USB keydrive in my Christmas pudding?
  • They need to fix ReiserFS is what they need to do, not keep mutating FAT further. With all their brains, they've gotta have someone who can figure out how to keep it fast and make it bulletproof. Oops, failure. FFR...

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close