Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sony Beefs up FAT for Consumer Devices

Posted by timothy on 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."

56 comments

  1. Wow, Sony just gained major cool points for that.. by ZephyrXero · · Score: 0

    nt

    --
    "A truly wise man realizes he knows nothing."
  2. Re:Wow, Sony just gained major cool points for tha by ZephyrXero · · Score: 1

    Now that I think about it....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...

    --
    "A truly wise man realizes he knows nothing."
  3. Still won't buy Sony products. by matria · · Score: 3, Insightful

    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.

    1. Re:Still won't buy Sony products. by poopdeville · · Score: 2, Funny

      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

      --
      After all, I am strangely colored.
    2. Re:Still won't buy Sony products. by spuzzzzzzz · · Score: 1

      OK, I think we've heard enough of that now. It was funny the first 5 billion times...

      --

      Don't you hate meta-sigs?
    3. Re:Still won't buy Sony products. by poopdeville · · Score: 1

      Hey, I know funny, and that was amazing it will

      - optimize seamless communities
      - generate vertical e-services
      - leverage synergistic convergence

      and best of all

      - engage e-business content

      --
      After all, I am strangely colored.
  4. Who to believe by superpulpsicle · · Score: 2, Interesting

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

    1. Re:Who to believe by Anonymous Coward · · Score: 0

      Sony needs to pay MS to use FAT? I don't think so. Surely the patents (if any) have expired ages ago. And secondly the Linux kernel has drivers for FAT and I don't recall any lawsuits for it.

    2. Re:Who to believe by Anonymous Coward · · Score: 0

      Quotation marks are not for emphasis.

    3. Re:Who to believe by gl4ss · · Score: 1

      *Sony needs to pay MS to use FAT? I don't think so. Surely the patents (if any) have expired ages ago. And secondly the Linux kernel has drivers for FAT and I don't recall any lawsuits for it.*

      actually ms tried to pull out some fat patents quite recently(for some fat changes that are not so old, well, they are OLD in computer world sense but not in the patent world).

      what i'm intrested more is.. is this compatible with vfat? can i just stick the device to a windows or mac machine and it will still work?

      --
      world was created 5 seconds before this post as it is.
  5. How many... by Creepy+Crawler · · Score: 2, Interesting

    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.

    --
    1. Re:How many... by TopSpin · · Score: 4, Interesting

      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.

      --
      Lurking at the bottom of the gravity well, getting old
    2. Re:How many... by david.given · · Score: 4, Insightful
      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...

    3. Re:How many... by Random832 · · Score: 1

      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 connector can just be pulled out. Some mechanism like a cd-rom tray (which won't eject until the OS is done with the disk) would be nice - something to let the OS lock the disk into place while it's in the middle of writing to it.

      The mac had this solved for floppies way back when they used floppies. Dragging it to the trash may have seemed unintuitive, but it had the advantage of being controlled by the OS - all windows could do was keep the little LED lit as it haplessly watched you eject the now-corrupted disk.

      --
      We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
    4. Re:How many... by Nutria · · Score: 1

      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 drives were the same.

      --
      "I don't know, therefore Aliens" Wafflebox1
    5. Re:How many... by Anonymous Coward · · Score: 0

      The mac had this solved for floppies way back when they used floppies. Dragging it to the trash may have seemed unintuitive, but it had the advantage of being controlled by the OS - all windows could do was keep the little LED lit as it haplessly watched you eject the now-corrupted disk.

      That has nothing to do with Windows. That's Mac hardware vs. PC hardware. The PC hardware was cheaper (fewer motors, gears, etc.) and left the OS (made by a different company) with little choice. The best Windows could do is say "wait, I wasn't done with that!" which iirc it sometimes did, on a blue screen.

    6. Re:How many... by Random832 · · Score: 1

      I wasn't implying that it was a problem with windows - just that windows (or linux on x86, etc) was provided with no tools with which to do anything but watch helplessly as you corrupt your data.

      --
      We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
    7. Re:How many... by spitzak · · Score: 1

      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 handle this and print an error message and act as though the file was missing.

    8. Re:How many... by cmowire · · Score: 1

      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.

      --
      Gentoo Sucks
    9. Re:How many... by Doctor+Memory · · Score: 1

      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?), they weren't mounted as file systems, just used as block devices. The chance that a drive would suddenly disappear with no warning and just as suddenly reappear was pretty remote.

      --
      Just junk food for thought...
    10. Re:How many... by Foolhardy · · Score: 2, Informative

      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.

    11. Re:How many... by Anonymous Coward · · Score: 0

      > You had *removable* disks, but changing a disk pack wasn't as simple as yanking a dongle

      "You keep using that word, 'dongle.' I don't think it means what you think it means..."

    12. Re:How many... by TopSpin · · Score: 1

      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 Sony would have had nothing to do. The historical problems with NFS that I mentioned are also cases of this problem. There are no valid reasons why a kernel should panic in the face of transient filesystems and hot pluggable devices. The fact is that *nix kernels take storage devices for granted and assumptions continue to be made in critical places. Today those assumptions are simply not valid.

      The second problem isn't as difficult as some postulate. Logging filesystems (XFS, JFS, EXT3, etc.) are all capable of surviving power loss without corruption. This is not substantially different than being disconnected arbitrarily. A log is one means of implementing a subset of ACID properties; the system transitions from one valid state to another instantaneously. There is no "in between" moment where the system is in an invalid state that would persist after being disconnected. Thus, there is no possibility of corruption [1].

      Solutions to both problems involve making conceptually simple things more complicated and less efficient. To what degree does optimization prevent solving either or both? You need both to exist sanely with hot pluggable or otherwise transient filesystems.

      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

      My point is that this must change. The problem has been ignored too long and it's high time to deal with it. This is a very hard thing; defining a policy that is supposed to apply generally to all implementations.

      (There's a good reason why most serious Unix hardware have software floppy drive eject mechanisms.)

      While there certainly are reasons, I remain unconvinced any of them are actually good. Making removable storage devices without a physical means to remove this media is a cop-out and always has been.

      My apologies if my critical and unbending positions on this are unpleasant. It's 2005; filesystems exist in all sorts of ephemeral places and every kind of media and I'm sick and tired of operating systems in general and *nix in particular pretending otherwise. It is not too early to expect better. Just ask Sony.

      [1] Corruption relevant to filesystem metadata only. The OS can make no guarantees about application data, although an application can a.) leverage the OS transactional capabilities or b.) implement it's own form of ACID behavior, as many DBMSes do.

      --
      Lurking at the bottom of the gravity well, getting old
    13. Re:How many... by The+Infamous+Grimace · · Score: 1

      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)
      --
      Ignorance and prejudice and fear
      Walk hand in hand
  6. why... by PrivateDonut · · Score: 1

    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. Re:why... by Rikus · · Score: 1
      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?
    2. Re:why... by 10101001+10101001 · · Score: 2, Informative

      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
    3. Re:why... by bersl2 · · Score: 3, Informative

      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.

  7. Crash??? by Foolhardy · · Score: 3, Interesting
    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?
    1. Re:Crash??? by KiloByte · · Score: 5, Informative

      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.
    2. Re:Crash??? by mibus · · Score: 1

      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! :)

  8. Just trolling, ignore me. by LittleBigLui · · Score: 2, Funny

    But will you be able to cp stuff off that filesystem or is it write-only?

    --
    Free as in mason.
    1. Re:Just trolling, ignore me. by flood6 · · Score: 1
      But will you be able to cp stuff off that filesystem or is it write-only?

      If you try to cp they su you.

      --
      SEO Firefox Extension
    2. Re:Just trolling, ignore me. by Dr.Dubious+DDQ · · Score: 1
      If you try to cp they su you.

      I call out once again to the slashdot coders - we need to add a "-1 Bad Pun" moderation. And a "+1 Bad Pun".

      --
      Hacker Public Radio is our Friend
  9. Sony Beef Fat? by Anonymous Coward · · Score: 1, Funny

    Is this a delicious new foodstuff?

  10. Re:Wow, Sony just gained major cool points for tha by tepples · · Score: 2, Informative

    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.

  11. whose IP are they violating? by cahiha · · Score: 1

    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.

    1. Re:whose IP are they violating? by Anonymous Coward · · Score: 0

      http://www.microsoft.com/mscorp/ip/tech/fat.asp

      At least one patent has been thrown out, but the above poster didn't "create it out of thin air" as you put it. Microsoft, at least at one point in time, actually had a valid patent on the FAT filesystem.

  12. Re:Wow, Sony just gained major cool points for tha by KiloByte · · Score: 1

    What they used, is one of the worst file systems in existence.

    FAT has big granulation (even as FAT32), it doesn't scale well, long file names support is an ugly kludge, it gives very little chance for recovery if the filesystem gets corrupted, etc, etc.

    Using any of existing file systems would give them a lot sturdier base than tweaking a CPM-era thing.

    --
    The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
  13. Last two stories on /. by tod_miller · · Score: 0

    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 a clever acronym to avoid being sued, real word rhymes with Boney. Think about it. OK if you haven't got it by now just give up.

    --
    #hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
  14. Hahaha by rincebrain · · Score: 1

    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.

    --
    It's only an insult if it's not true.
    1. Re:Hahaha by tomstdenis · · Score: 1

      Correct saying would be "swing and a miss".

      Tom

      --
      Someday, I'll have a real sig.
  15. I have to admit, I'm skeptical by croddy · · Score: 5, Informative
    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???

    1. Re:I have to admit, I'm skeptical by MarkGriz · · Score: 1

      Wait...

      Yep, it just passed an fsck.

      Sony, what are you smoking???
      After reading about your investigative test results, Sony has decided to just stick with vFAT technology.
      However, it plans to market it as "pHAT", since it is *so* much cooler.

      --
      Beauty is in the eye of the beerholder.
    2. Re:I have to admit, I'm skeptical by Anonymous Coward · · Score: 0

      What happens when the write has already succeeded, the file is closed, and the data is in the cache waiting to get written -- but then you pull the USB device out before the write completes?

      dom

    3. Re:I have to admit, I'm skeptical by croddy · · Score: 1

      I don't understand the question. Removable devices are why we have the 'sync' mount option.

  16. Vaporware by bcmm · · Score: 1

    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.

    --
    # cat /dev/mem | strings | grep -i llama
    Damn, my RAM is full of llamas.
    1. Re:Vaporware by tomstdenis · · Score: 2, Informative

      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.
  17. Re:Wow, Sony just gained major cool points for tha by Directrix1 · · Score: 2, Interesting

    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).

    --
    Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
  18. Re:Wow, Sony just gained major cool points for tha by Directrix1 · · Score: 1

    Uhh, Sony is just improving the VFAT driver for linux because it has problems. Every USB Mass Storage device uses FAT, thats why this is an issue. I understand FAT sucks monkey balls, but that doesn't stop it being a popular partition in the Windows world, and hence the rest of us have to put up with it.

    --
    Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
  19. BEEFS up FAT, eh? by hey! · · Score: 1

    Does this mean I'll be finding a USB keydrive in my Christmas pudding?

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  20. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  21. What were they thinking? by suitepotato · · Score: 1

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

    --
    If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
  22. Re:Wow, Sony just gained major cool points for tha by m50d · · Score: 1

    Is there any effort to make one for reiserfs anywhere? I use reiser on my linux partitions and it would be nice ot be able to access them from windows.

    --
    I am trolling
  23. The filesystem paradox by MS-06FZ · · Score: 0

    What happens when the write has already succeeded, the file is closed, and the data is in the cache waiting to get written -- but then you pull the USB device out before the write completes?

    You become your own grandpa.

    --
    ---GEC
    I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand