like NTFS, HFS+ or ext4, for SD cards? After all, journaling decreases the chance of data loss, which would be important for photographers. I lost an SD card containing maybe a thousand photos when in Bali -- a place I haven't got a chance to visit before or since.
Are there any precautions I can take before a trip the next time? Format the cards in camera?
Am I correct in understanding that SDXC (exFAT) and Sony Memory Stick offer no more reliability than SD cards?
Let's do a little cost benefit analysis:
A journaled file system is more complicated - this means longer development time, more bugs, more battery power drain, higher production cost etc.
the problem solved by a journaled filesystem - corrupted FS data but file data intact - is handled pretty well by 3rd party data recovery tools.
journaled file system does not solve all problems, you really need good backups - and not only that systems with built-in backups exists (dual card slots) it's a feature that is used to make pros get more expensive cameras.
there isn't a big memory card reliability crisis, those cards are pretty reliable and failure is relatively rare.
and finally, there is no journaled file system that is supported out-of-the-box on both Windows and Mac.
So - if you were the product manager in charge would you approve a project that 1. solves an already solved (with 3rd party tools) problem in an incomplete way, 2. is not important enough to be a selling point and 3. will make a significant part of the market unable to use the camera (at least without installing additional software they won't need with the competing brands)?
Journaled file-systems only ensure the integrity of the file-system. If a card truly fails, it fails with the whole file-system. Now if you have some bad memory cells, you would only use whichever photo occupied that space and a journaled file-system would not help either. In other words, this is the wrong solution to the incident you describe.
The real solution is redundancy which is why you will find high-end offerings from Nikon, Pentax and Canon which offer dual memory-card slots and the ability to write images to both cards at once. This gives you an instant backup. If those cameras are not convenient to you, the you have to find some other way to make frequent backups. Some people do it daily onto a laptop, portable drive, optical-disk.
While I have not tried this yet and am not sure how practical it is, you can also use a WiFi device or card (SD/SDHC only AFAIK) which automatically sends your images as they are captured to another networked device, maybe a tablet or something with good storage.
While SDXC comes format as exFAT by default, you can format it yourself at FAT32 too. Most cameras will accept it both ways. The difference in reliability is probably zero though.
It comes down to resolving "is there a market?" and "what are the barriers to adoption?". Each of those presents a huge barrier to adoption even if it were worthwhile.
NTFS would incur costs for licencing even if a suitable library even exists for the camera's processors (which is not guaranteed) and support outside of Windows would be patchy. While HFS+ and ext4 have no native support in Windows, eliminating much of the potential customer base. So there's no market for those.
As you mention, exFAT is required by the SCXD standard so you'll see that as support for larger and faster cards appears but it's not as simple as that since more code is also more to go wrong, and with embedded systems like cameras, you really don't want to push out firmware updates so expect that while writes to an exFAT card might be readable and in the right format, it may not actually use any of the exFAT features that might offer any protection. So there are significant barriers to adoption too.
The failure mode of most cards is as likely to be the controller as a memory cell it is a lot of work (cost to manufacture) for little benefit.
Sony MS (MemoryStick) is still SLC or MLC flash memory, it's just the controller and physical connection which differs between the systems. Your best protection in the situation you've experienced is to take a small portable backup device with you, they are pocket sized and relatively inexpensive (and probably incompatible with Journaled filesystems too.)
As far as I know, all digital cameras produced to be sold on the retail market incorporate the Design rule for Camera File System (DCF). Part of the DCF standard is that the FAT file system must be used by compliant devices. This standard was adopted as the de facto standard for storing digital image and sound files in memory devices by the digital camera industry to insure interoperability from one brand to the next.
See https://photo.stackexchange.com/a/46387/15871 for more information about DCF.
One obvious reason: because a journaling filesystem on a camera very likely would not have helped you (or anyone).
As a very high level overview, here's what a journaling filesystem does: Before each write to the metadata (or data, if data-journaled as well), first write what you're going to change to the journal. Only once you're sure that's on disk, go ahead and write the change. Basically, this means that if power is interrupted during the write, you can recover the filesystem by using the journal—you go ahead and perform any actions in the journal.
This is valuable on a desktop PC, where the power might go out, or the user may hit the reset button, or pull the plug, etc. Also valuable, but less so, on servers (power failure) and laptops (reset button).
A camera is battery-powered. It has an off switch, but this normally tells the firmware to shut it down—it isn't a physical power disconnect. There isn't usually a reset button, or if there is, its basically never used. So, you don't need journaling, the firmware can just finish the write. The only exception would be if you physically removed the battery. Maybe that'd happen with an external power pack, but other than that, a camera should never experience an unclean shutdown.
Also, almost no flash devices actually handle unexpected power failure well. Get them in the middle of a sector relocation (wear leveling), and all bets are off. So even if you had a journaling filesystem, you'd still not be safe from power failure.
A journaling filesystem does not protect you from:
In fact, a journaling filesystem is more complicated, so you are actually more likely to have filesystem bugs. It amplifies writes, so you're more likely to hit flash controller or SD host bugs. And you're going to wear out the flash slightly sooner.
Journaled File systems are bad for SD cards (or any NAND Flash device).
Write operations are expensive for NAND Flash devices and journaled file systems tend to write more than non-journaled file systems for the same activities.
So the SD card will work slower and will last less with a Journaled file system.
FLASH-based storage, at its core, uses a technology called NAND FLASH. NAND FLASH is readable and writable, but with several wrinkles.
The fundamental read/write unit is a "page", not a sector. FLASH devices of the 2007-2008 generation have a 2K page size, migrating to a 4K page size in the 2009 generation and 16K page sizes have been observed in 2011 generations.
You can't write a page anytime you want - before you write to it, you must first erase it. But you can't erase a single page at a time - you must erase an entire "erase block" of (typically) 64 consecutive pages (128Kbytes or 256Kbytes depending on the generation). And after you have erased the block, you can't write to the pages in an arbitrary order, you must write them sequentially starting at the first one.
Blocks tend to wear out over time. After a certain number of erase cycles, a block will "go bad" permanently, so that it will no longer reliably hold data. Pages can also develop data errors as a result of write activity to other pages, and even as a result of reads!
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device
Edit: It is worth to mention that Journaled File systems will not bring significant advantage over non-Journaled File systems.
Different file systems require different amount of RAM in a system that is using them. A system that needs to write a file to a FAT file system could in theory get by with a single 512-byte buffer, though performance would be pretty dreadful. Expanding to two or three 512-byte buffers would improve things enormously. Going beyond that would improve things somewhat more, and getting optimal performance from a larger card would require more memory than getting optimal performance from a smaller one, but a camera which only included enough buffers to achieve optimal efficiency with smaller cards would still be able to work with larger ones, even if less efficiently.
A trickier issue centers around the fact that memory-card standards specify that each card behave as a numbered collection of 512-byte sector that can be read and written independently in arbitrary sequence, but that's not how the data is stored on the chips within the cards. The memory chips used in a typical memory card are divided into 528-byte pages; those in turn are grouped into blocks of 256 or more. Once a page is written, it cannot be rewritten without erasing it and all the other pages in its block. In theory, it would be possible for an SD card to honor a request to write a 512-byte sector by copying to RAM all the data in its block, erasing the block, and writing the whole block back but with new data in one sector. In practice, performance would be dreadful. Instead, writing a sector will cause the SD card to pick a blank page, write the data there along with its sector number and various ancillary information (the reason pages are 528 bytes rather than 512), and somehow keep track of that being the proper location for the data. When blank pages get to be in short supply, the controller will identify a block whose pages have been mostly superseded by pages written more recently, copy all still-current pages from that block to blank blocks, and then erase the entire now-redundant block. All this logic is handled entirely by the card itself, without any intervention by the camera.
All this logic means that in addition to the FAT32 or other file system seen by the camera, the SD card will need to have its own block allocation and management system. Any problems that occur in that system are likely to cause data loss, regardless of what sort of system sits on top of it. In theory, many memory cards are designed to ensure that even if power is unexpectedly removed during some operation the card will be able to either roll back the state of the card to what it was before the operation began, or else run it to completion (if all the necessary data had been written, and the card was simply cleaning out redundant data). Unfortunately, cards differ in how well they implement such logic. If unexpected power loss clobbers the storage management tables of a card, software which understands the inner workings of such tables might be able to recover data which is invisible to any software that simply uses the sector-based read-write interface.
Personally, I think it would have been better for the SD Consortium to specify a file system independent of FAT32, or at minimum specify that even if a card had to be readable as a FAT32 volume, it should be written using a file-based communications protocol. A card which knows which groups of sectors are members of each file could optimize its defragmentation routines around that, and could also do a better job of protecting against data loss than could one which had to present the disk as a bunch of independent 512-byte sectors, but for better or for worse that's not how things are specified.
Assuming the card was simply corrupted, and you haven't tossed it or overwritten it, I strongly suggest you try PhotoRec. (It got me out of a slightly less bad situation a few months ago. It even found a few images that had survived being deleted for a year or two.)
http://www.cgsecurity.org/wiki/PhotoRec
Regarding a journaling FS, I've had the same question many times. As others have said, current flash media actually is fragile compared to magnetic media, and journaling is hard on it. Since the usage pattern for cameras is generally take a bunch of photos, read them, then delete them all, there isn't much need for advanced FS features. Simple, tested implementations are probably more important than the marginal benefit of journaling. As an added benefit, the dumb allocation strategy of FAT makes it easier for tools like PhotoRec.
1, God cannot save you, if you physically lost the card. What do you mean you lost a card in Bali?
2, Journaled FSs are built for occasions like sudden OS-failure or sudden power-failure. They keep the FS meta-data consistent, when those bad things happen. They are not helping if you want your deleted files come back.
3, Bad-block is the most vital problem of the NAND FLASH based storages. Bad-blocks come up when writings occur. Hence, when choosing FS for a NAND FLASH storage, writing frequency is the first thing you should consider. Obviously, like all the others said, Journaled FSs bring more things to write.
4, Journaled FSs take more power, of course. More complicated, sure. But these are not the dominant reasons that we don't adopt them for NAND FLASH, I think.
TADA~~ That's it.
The file system itself does not need to be complex because images are simply written to the card, there isn't hardly any editing done to a file after initial creation and there aren't simultaneous file I/O concerns that need to be worried about on the camera.
The data integrity issues are actually solved at a hardware level because ALL flash memory is inherently unstable. The controller within the SD card does a lot of its own checks and storage tricks to ensure that the data is valid. A journaling file system would do nothing to help with this as it deals with the integrity of the data storage rather than the integrity of the file operations.
A camera uses such simple (and high speed) file operations, that a complex file system would incur additional cost and complexity, causing slower I/O and potentially introducing further bugs that could result in data loss due to more complex file handling, while not gaining anything of use to a camera.
