Flash Drives Wearing Out ?

[jaclaz]

While being good for access, just be wary of the ones you get as alot of budget line ones will in fact suffer greatly with impaired performance due to the controller. It's best to check reviews for flash drives to determine which would be best for the needs (read/write limitations, speed, etc).

Yes, there is a GREAT difference between "el-cheapo" "no-name" and "top level" sticks, often there is a 4x or 5x speed factor in comparative tests.

So, they do take some time to wear out even with excessive amounts of accesses under a FAT32 filesystem. You should be pretty safe at least for 2 years from experiences here if you consistantly use it on a daily basis for heavy amounts of transfer.

Yes.

The problem is not the massive read access (no or very little wear derives from it).

Nor the write of huge chunks of data (as it will take time and it counts anyway as a single write operation).

So, with FAT16 or 32 or EXT2FS it isn't likely that there will problems soon , unless you defrag constantly a filled up to the brim filesystem.

NTFS or EXT3FS do at least one write operation for each READ one, that and as well the activity of a swap file can wear a stick in weeks of use, if it has not wear leveling capabilities.

The Optima-Pro should be a PNY, that I think uses a UT165 from USBest, which actually HAS wear leveling:

http://www.forensicfocus.com/index.php?nam...sc&start=34

A wear leveling algorithm, depending on several factors, like the amount of "fill" the filesystem is at, can easily introduce a x10 to x30 factor in life of the device, but it also greatly depends on the type of wear leveling algorithm (static vs. dynamic).

A couple of resources with some actual figures:

http://blog.datalight.com/flash-wear-leveling

http://www.flashmemorysummit.com/English/C...1_F2B_Roman.pdf

AFAIK, the whole idea of a IFS (Installable File System) is post-DOS.

In DOS the filesystem needs to be inside the kernel.

There are LTOOLS, though:

http://www2.hs-esslingen.de/~zimmerma/software/ltools.html

jaclaz

Edited December 16, 2009 by jaclaz

[dencorso]

AFAIK, the whole idea of a IFS (Installable File System) is post-DOS.

No, it's not!

IFS in DOS are implemented as device drivers or use the network redirector.

MSCEDEX.EXE just comes to mind as the more widely known example.

I think there's a definite possibility that someone just may have written some ext2 driver, too.

Let's search a little for it and see what do we find.

For what''s worth, here is a comparative pendrive test I've conducted, in as similar conditions as possible: (link).

[jaclaz]

AFAIK, the whole idea of a IFS (Installable File System) is post-DOS.

No, it's not!

IFS in DOS are implemented as device drivers or use the network redirector.

Yes, it is.

A device driver as an executable is really a device driver, MSCDEX.EXE "drives" the "unknown" hardware (the CD-ROM device), not only the filesystem.

You could have taken a better example, like NTFS4DOS to prove your theory.

But I won't argue with you on definitions.

http://en.wikipedia.org/wiki/Installable_File_System

JFYI:

http://www.pcausa.com/resources/ifsqlist.html#AnchorCPhantom

http://decuslib.com/decus/vmslt99a/nt/

http://groups.google.com/group/comp.os.msd...f208bd4668f2090

http://coding.derkeiler.com/Archive/Assemb...7/msg00198.html

jaclaz

[rloew]

A device driver as an executable is really a device driver, MSCDEX.EXE "drives" the "unknown" hardware (the CD-ROM device), not only the filesystem.

You could have taken a better example, like NTFS4DOS to prove your theory.

MSCDEX.EXE is an IFS only. It is not a CD-ROM Device Driver. A CD-ROM Device driver needs to be loaded first.

[jaclaz]

MSCDEX.EXE is an IFS only. It is not a CD-ROM Device Driver. A CD-ROM Device driver needs to be loaded first.

I won't argue with you, either over this thing.

If everyone is happy with calling this feature IFS, it's allright, I stand corrected, and everyone is happy.

jaclaz

[dencorso]

Sorry, jaclaz, I don't want to argue either, but there is more to be said.

RLoew and me are far from being the only ones that consider MSCDEX an IFS, or to say that there are IFSs in DOS.

I could have stated it better, though, so I'll amend my original statement to:

IFSes in DOS are implemented either as TSRs or as device drivers (in form only), either standalone or, preferably, using the network redirector (as fictitious remote filesystems).

See: (i) Andrew Schulman, Raymond J. Michaels, Jim Kyle, Tim Paterson, David Maxey and Ralf Brown, UNDOCUMENTED DOS, chap. 4, p. 153-259, 1990, ISBN 0-201-57064-5, and (ii) Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michaels and Jim Kyle, UNDOCUMENTED DOS 2nd ed., chap. 8, p. 401-540, 1993, ISBN 0-201-63287-X.

MSCEDEX.EXE is a good example of IFS:

That this is not necessarily just a network issue is shown by the Microsoft CD-ROM Extensions (MSCDEX), a fascinating piece of software that uses undocumented DOS file system features to make a CD-ROM appear like a normal DOS device. Obviously, there must some features in DOS that allow you to write fiction, as it were: taking a CD-ROM with the High Sierra or ISO-9660 file system and making it look as though it were a standard DOS device with a File Allocation Table (FAT) filesystem.

You can think of how it's used:

[PATA CD/DVD writer] --> oakcdrom.sys (the true device driver) --> MSCDEX (the ifs) --> DOS kernel --> UI

[uSB CD/DVD writer] --> usbaspi.sys + usbcd.sys (the true device drivers) --> MSCDEX (the ifs) --> DOS kernel --> UI

While one cannot read the source to MSCEDEX.EXE, one can read sources of various versions of shsucdx.exe (found here and here, which is even more full-featured than MSCDEX), a truly interesting reading.

Your examples are very apt,

JFYI:

http://www.pcausa.com/resources/ifsqlist.html#AnchorCPhantom

http://decuslib.com/decus/vmslt99a/nt/

http://groups.google.com/group/comp.os.msd...f208bd4668f2090

http://coding.derkeiler.com/Archive/Assemb...7/msg00198.html

Note, however, that the best version of Phantom is in ref. (ii) and in its companion diskette: it's implemented as a fully usable XMS ramdisk (with source, of course).

...

Now returning to ext2, I've still not found a DOS IFS for it, but there are reader programs for DOS: dft, EXT2TOOL and LREAD10 (findable in the very interesting page Filesystems-HOWTO). Here there is more on EXT2TOOL