I just run flash drives like they were regular drives. They almost never really wear out. They suffer size/price so I get a new larger one. They suffer getting left in pants and go through washer. They suffer esd and shock but they almost never just wear out.

I totally agree. There are certainly a ton of users who are going to relate their stories of how a flash drive died on them, this is the randomness of life. My personal experiences are more along the lines of what jefro says there.

OP I wonder how the original proposed project went?

I also do wonder if anyone has seen or knows of any utilities which would the health of any given flash drive? There's extending the life, but there's also variances in manufacturing and as a result you can take two identical drive models and one is a klunker where the other one lasts for years. With magnetic drives there is an interface; I thought through ACPI, which advanced disk analysis tools can use to assess the amount of usage and time in service; no direct judgements but at least statistics where someone can make their own assessment. Does anything similar exist for flash drives?

This is what I was referring too, the drive needs to support SMART:

http://www.linuxquestions.org/questi...6/#post5148427

Hi there,

alright, but why would one want to do this? True, FAT32 has that file size limit of 4GB. But apart from DVD images, virtual HDDs for a VM or very large video files I haven't yet had a situation where that limit actually mattered. True, FAT32 is proprietary and not officially documented, but yet widely known thanks to diligent reverse engineering of many experts, and is supported by a vast scale of systems from big servers across desktop systems down to the embedded sector - just think of digital cameras or hard disk video recorders or TV units with PVR function on external USB media.

And even if file size did matter, UDF would be about the last thing I'd choose, especially for compatibility reasons. If you're going to use the external media with Linux only, you can safely use ext2/3/4. But if compatibility with Windows machines AND files beyond 4GB are a necessary requirement, UDF is a lottery game. Better even to use NTFS, which is proprietary, but supported by all contemporary Linux distros out of the box.

Incidentally, the only context where I encountered UDF so far is CD packet writing - with all the counter-indications mentioned above. So from my point of view, UDF is a dead birth.

[X] Doc CPU

Just because you don't come across the file size limits of FAT doesn't mean nobody else does. I admit I probably came across it first when "trying to back up DVDs for friends" but now when I'm sometimes backing up VM hard drives, distribution DVDs or just long videos (the file I was copying earlier in this thread is the free Bergensbanen video) I couldn't cope wit ha limit on file size.
I'm not sure that UDF is the answer but my experience with Linux's NTFS support leaves a lot to be desired so I don't feel it is a better choice.
Any reverse engineering of FAT32 is also potentially illegal, you understand, since these wonderful new laws like the "digital millennium copyright act" came into existence. It really is time we stopped giving MS reason to spread FUD and used a different file system.

This evening I copied just over 22GB to two flash disks. So far Windows (XP up), Slackware and NetBSD have had no problems reading from and writing to these UDF-formatted disks. As you say, why oh why? Here in UDF we have a decent file system which is inter-operable across different operating systems. I am completely new to UDF but for the life of me I can't understand why this thing didn't take off long ago and leave all the others in the dust.

If Pat is reading this, I would like to politely ask for the inclusion of udftools in Slackware. It is a small utility and in my opinion once the benefits of UDF are known then UDF becomes as important a filesystem for portable devices as ext{2,3,4} is for HDDs.

Hi there,

oh, mind you - I do, and frequently so with video files (raw MPEG TS recordings from TV).

NTFS itself leaves a lot to be desired, most of all stability and reliability. Back in the time I used Windows, I usually avoided NTFS, as I've experienced several serious Windows crashes (from NT4.0 up to XP) that left the file system damaged beyond repair. On a FAT (FAT12,16,32) volume, similar accidents would typically corrupt a handfull of files, but on the whole leave the system recoverable. FAT is, let me say, robust and sturdy because of its simplicity.

Well, I shouldn't have used the term "reverse engineering", because I meant something slightly different: The available information about the FAT family is sufficient for programmers to implement their own FAT file system driver. And many did; FAT16/FAT32 implementations are available from third-parties in a great variety.

[X] Doc CPU

Well, yes, but any FAT implementation is potentially subject to a Microsoft injunction or demand for payment. You only have to look to Tomtom being effectively killed off by Microsoft over it, the Microsoft tax on every Android handset sold in the US and the US legal system's handing over of No-IP to Microsoft to see that anything even vaguely related to Microsoft can and does cause problems to all involved. In these days where the US legal system has declared itself for sale to the highest bidder I find myself not wanting to rely upon any software product a US firm may have even the slightest claim to.

Why would there be a Microsoft tax on Android devices? Android uses ext4. It can read FAT-formatted cards, but it doesn't use that filesystem otherwise.

It uses FAT that's enough. Doesn't matter whether some devices never use FAT -- the code is there and the US government wants MS to get its cut.
http://www.zdnet.com/microsofts-most...id-7000015094/

Some posters here have brought up the question of UDF being compatible with modern OS's. Here is an article that explains that issue in detail.

Actually for newer flash chips the possible number of erase cycles for each erase block did take a large hit. But number of erase-cycles multiplied by the number number of erase blocks did increase. Modern SSDs are huge. 16 GB for is two complete overwrites for an ancient 8 GB SSD (with 100k erase cycles) of an early netbook, but nothing for a modern 1 TB SSD (with 3k erase cycles NAND). Conclusion: These newer Flash cells wear down 32 times faster, but there are 128 times more of them, so it doesn't matter.

There are multiple issues with UDF in Linux. The Linux implementation of UDF is bitrot code, so it is only safe for ready-only use. The udftools haven't been updated for decade, too. USB flash drives expect to operated with large blocksizes like 32 KiB (for FAT32). Setting the block size to 512 as proposed on the blog will kill the flash memory with read-modify-write cycles.

The specifications of FAT12, FAT16 and FAT32 are public, patents only cover LFNs ("long file names") and will expire in this decade. The proprietary successor is "Exfat", but even that is better supported by Linux than UDF. The right way to deal with such stuff, is using an alternative LFN solution on top of FAT (like the OS/2 one), making it incompatible with Windows 95. But in the mobile sector (where MS makes most of its FAT license money) Windows becomes irrelevant anyway.

2 members found this post helpful.