Author Topic: SSD File System Recommendations (Read 31433 times)

yksyks · « **on:** May 08, 2009, 06:01 AM »

Recently I got my wife an Acer Aspire One notebook with WinXP, 1 GB RAM and 16 GB SSD. It's surprisingly nice little machine, especially with regard to its price (I got it for free when buying a lawn mower).

It was pre-installed and I'm surprised it has FAT32 file system. I've read many diverse and divergent articles, but it seems that converting to NTFS would be a good idea to speed it up a bit. But what about the cluster size? The only thing those articles seem to agree is that it's quite critical value for an SSD, but they don't give any unambiguous answer.

Does anyone here have any experience or piece of advice? Thanks in advance.

4wd · « **Reply #1 on:** May 08, 2009, 01:44 PM »

Recently I got my wife an Acer Aspire One notebook with WinXP, 1 GB RAM and 16 GB SSD. It's surprisingly nice little machine, especially with regard to its price (I got it for free when buying a lawn mower).

It was pre-installed and I'm surprised it has FAT32 file system. I've read many diverse and divergent articles, but it seems that converting to NTFS would be a good idea to speed it up a bit. But what about the cluster size? The only thing those articles seem to agree is that it's quite critical value for an SSD, but they don't give any unambiguous answer.

Does anyone here have any experience or piece of advice? Thanks in advance.
-yksyks (May 08, 2009, 06:01 AM)

NTFS is not a real good filesystem for SSDs, it does too much housekeeping, (ie. writes), which can reduce the life of them.

I also have an AAO, 512MB RAM, 8GB SSD Linpus originally, now 1.5GB RAM and running a much nlitened version of XP Pro. The biggest speed up is by not having the thing write to the rather crappy SSD, (at least the 8GB is), in the first place.

See my post here about using Microsoft's Enhanced Write Filter to redirect system writes to RAM i.l.o. SSD.

If you're interested I'll elucidate further but right now it's 0440 and I'm off to bed.

Oh, a couple of good resources:
Aspire One User
macles*

yksyks · « **Reply #2 on:** May 08, 2009, 01:58 PM »

Thank you, I've already read your post before. And thanks for other links, too.

I'm not afraid of NTFS because of shortening the SSD's lifetime, based on articles like this. In fact, I already decided to go for NTFS, especially with regard to synchronization to other machines which utilize NTFS, and would prefer to avoid having twice a year the havoc of all files timestamp shifting.

I'm just not sure about the cluster size. Is it really so critical?

4wd · « **Reply #3 on:** May 08, 2009, 09:30 PM »

I'm just not sure about the cluster size. Is it really so critical?
-yksyks (May 08, 2009, 01:58 PM)

I think that the default that Windows gives, (4kB for disks >2GB), is probably the best all-round compromise so I would leave it at that.

If you want to get really technical you could calculate an average, (as that is really all it is), as given here.

If you want to speed up your SSD access a bit you could also try FlashPoint SSD accelerator. The forum discussion regarding its performance and any problems is here.

f0dder · « **Reply #4 on:** May 09, 2009, 11:19 AM »

EWF is a nice thing and all, but imho not suitable for normal desktop (or laptop, for that matter) use - power loss or BSOD, *blam*, all unsaved data gone? No thanks.

NTFS doesn't really do that much more bookkeeping than FAT, but it does do fs metadata journalling which I wouldn't want to be without. You'll probably want to disable "last access-time timestamps" (iirc Vista does this by default, but XP certainly doesn't).

As for cluster size, dunno... if you start speculating in this, you'd have to know the erase-unit size of your flash, and you would have to get your partitions aligned to this boundary as well... otherwise it's pointless.

yksyks · « **Reply #5 on:** May 09, 2009, 03:41 PM »

I completely agree with both of you. EWF seems to me too dangerous. How about the FlashPoint? Is it worth trying? Some speeding up would be nice, but the data reliability is the highest priority, you know.

By the way, is there any significant improvement when disabling the last access time timestamps? I'll do this on the SSD, but how about normal HD? Any personal observations?

4wd · « **Reply #6 on:** May 10, 2009, 06:52 AM »

I completely agree with both of you. EWF seems to me too dangerous. How about the FlashPoint? Is it worth trying? Some speeding up would be nice, but the data reliability is the highest priority, you know.
-yksyks (May 09, 2009, 03:41 PM)

Since we are talking about the Acer Aspire One, then I have experienced no data loss at all no matter how I've turned the machine off, or not commited changes, etc, etc.

For the simple reason is that I use the System Expansion SD card slot on the left for all my data, (there's a 4GB or 8GB SD card in there all the time). That card is where 'My Documents' resides, where files are downloaded to, etc, etc.

EWF is only enforced on C:\ where the system and any programs are, portable or installed. The programs and system are set up the way I want so I don't care if the system is turned off incorrectly - the only data lost is whatever the browser may have cached and other junk which isn't necessary for the running of the system. The system boots in the same state it was the last time it was turned on, and the time before that, ad infinitum.

Unless I have committed changes to it - and that only happens when there's a new program install or I've changed settings in a program that I want to keep.

EWF is not dangerous providing you use it as it was intended.

I also use it as a cheap form of virus protection since any changes a virus makes to the system drive can be removed by just turning it off, (providing you haven't committed changes).

If, however, you are not prepared to use a separate means of saving your data, whether the SD card or dividing the SSD into two partitions and keeping your data on the second, (which you should do anyway), then yes, EWF is not for you.

In that case you could use FBWF with it's ability to specify some directories on the drive as writable even though the rest of the disk isn't.

f0dder · « **Reply #7 on:** May 10, 2009, 07:08 AM »

4wd: good point - for that kind of setup, it does make sense. I'm still slightly skeptical wrt. the registry not being persisted, though.

As for last-access timestamp, it did make a speed difference back when I originally turned it off. Disks are faster nowadays, so it might not be as big a speed hit... it does mean unnecessary read-erase-write cycles on an SSD though, and why waste your time on bookkeeping that you most likely won't be needing?

4wd · « **Reply #8 on:** May 10, 2009, 08:07 AM »

I'm still slightly skeptical wrt. the registry not being persisted, though.
-f0dder (May 10, 2009, 07:08 AM)

If it helps, think of it as a improved version of a WinPE, (or BartPE), CD - there's no need of a persistent registry since the system doesn't change.

After all, what registry changes are really stored when you have your system the way you want it?

Basically, any program setting changes, (for those that store them in the registry), and recent documents opened.

I honestly can't think of anything else that requires the registry be constantly updated.

How about the FlashPoint? Is it worth trying? Some speeding up would be nice, but the data reliability is the highest priority, you know.
-yksyks (May 09, 2009, 03:41 PM)

I tried it, it worked (except for a bug regarding chkdsk which has been fixed in the latest version), but gave me nowhere near the speed as my current setup does - which is to be expected, writing to RAM or the slow SSD - RAM is going to win.
With my current setup my data is as safe as yours would be, probably safer because it's not all on a drive that's being constantly written to. Plus I can simply eject the SD card, toggle the Lock switch and plug it into a reader on another PC to transfer it without fear of accidentally deleting it.

Remember, FlashPoint is beta software so if you're not prepared to wear potential data loss then don't use it.

EDIT: Just another point about EWF/FBWF while I think of it: defragging - do it once, enable EWF, no need to do it again

Kamel · « **Reply #9 on:** May 10, 2009, 10:57 PM »

I definitely agree that FAT32 is probably fastest. NTFS has more bells and whistles, but there is overhead involved in maintaining that. Even if the cluster sizes (automatically adjusted in NTFS) are more optimal, the most advantage you will see is perhaps the ability to put a tiny bit more on the ntfs volume due to more sensible cluster sizes.

yksyks · « **Reply #10 on:** May 11, 2009, 03:48 AM »

To 4wd: That's a nice setup idea. For the moment I'm going to stick with more or less standard setup, though, as it's not my PC.

To f0dder: I suppose when disabling the last access time timestamps improves significantly the performance of an HD, the more it should be apparent with SSD, right?

To Kamel: I don't think so. In my experience when I reformatted a bunch of old HDs, which I'm using now as external via USB, from FAT32 to NTFS, I got an increase in performace 5 to 10 times faster, both reads and writes. This might not apply to SSD, of course.

On the other hand, I prefer NTFS not only for speed, but also for those bells and whistles, like journalling, shadow copy, etc.

f0dder · « **Reply #11 on:** May 11, 2009, 05:26 AM »

yksyks: there's probably a lot bigger speed gain to be seen from disabling last-access timestamp update on SSD than on mechanical disks. Why? It's tiny data - mechanical disks are addressed in 512-byte sectors. SSDs are organized differently... the block size is larger, and even worse you get the "erase unit size" which is multiple blocks large. When updating data on an SSD, you get a sequence like the following (doesn't take some of the more advanced latency-hiding and lifespan-improving SSD features into account)

[Select]

1) read entire erase-unit-size block
2) merge modified data
3) erase block
4) write block

Would be interesting to see some benchmarks of NTFS vs. FAT, but I'm pretty convinced that
1) FAT wouldn't be faster
2) people would do the benchmarks wrong

4wd · « **Reply #12 on:** May 11, 2009, 06:37 AM »

To Kamel: I don't think so. In my experience when I reformatted a bunch of old HDs, which I'm using now as external via USB, from FAT32 to NTFS, I got an increase in performace 5 to 10 times faster, both reads and writes. This might not apply to SSD, of course.
-yksyks (May 11, 2009, 03:48 AM)

IIRC, from doing a lot of PE builds to flash drives, using FAT32 on an external USB drive isn't recommended because XP reads it slower than NTFS or FAT16.

The end result is if the drive is 2GB or smaller, use FAT16. If it's bigger, use NTFS unless you need compatibility with another OS.

Kamel · « **Reply #13 on:** May 11, 2009, 07:14 PM »

I know for a fact that FAT32 in many instances is of a much greater speed than NTFS... However, that would be specifically in certain environments. For instance, with slower processors etc. If hardware were not an issue, which is faster would be a good question. Theoretically, I suppose NTFS "should" be faster, but the software and hardware mix surely has to be optimal for such a thing to hold true. I am unaware of the instances when NTFS might be faster or slower, but I definitely know that FAT32 had much faster data retrieval time for me.

Having said that, you are wondering how I know. How I know would be my experience with programming lost (deleted or otherwise destroyed file tables) file recovery programs. NTFS believe it or not was simpler for us to use but FAT32 was ultimately faster. Further, the tests were over linux and windows (all of it substantially slower all together on linux).

I suspect that windows tries very hard to get NTFS accepted as a new file system standard so they may work much harder at optimizing the read speed of NTFS in the windows drivers. That's a whole different can of words, but suffice to say that I have read ~800 pages of file system forensics so my guess isn't completely uneducated. It also isn't complete truth though, as the intent of what I was doing was never to compare speeds of the 2 methods, I just happen to notice it while working on the project.

I hope that clears up my position on the subject a little better.

4wd · « **Reply #14 on:** May 11, 2009, 09:11 PM »

While we're talking about filesystems - there's one that hasn't been mentioned yet: exFAT^w

As WikiPedia says: ...suited especially for flash drives...

Now I'm not sure whether they mean USB or flash drives in general but it can be read by XP (with Hotfix), Vista SP1 and Linux (free kernel module).

Implemented in Vista SP1, it's now available for XP SP2/3.

The XP driver is available from Microsoft here.

The only thing against it is that it is proprietary to Microsoft.

A search over at MSFN will show a lot of threads, mostly pertaining to USB flash drives.

EDIT: I found what seems to be the original article mentioned in MSFN forums but not referred to: Tech Recipes

The article is dated 28-Feb-2008 and I found that the paragraphs at the bottom possibly summed it up nicely:

Interestingly enough, exFAT is not used currently for formatting hard drives. It is being recommended in Flash memory storage and other external devices only. This is why it is currently not considered a huge competitor to NTFS on hard drives.

However, exFAT should be a true competitor to NTFS on systems with limited processing power and memory. NTFS on flash memory has been known to be inefficient for quite some time. exFAT’s smaller footprint/overhead makes it ideal for this purpose. Of course, only if your definition of “ideal” allows software to be proprietary and not open source.

Vista will happily read FAT, exFAT, and NTFS from flash. ReadyBoost may not work with exFAT formatted flash drives, however.

In conclusion, basically, FAT is a simple system. This limits FAT system by losing efficiency at large sizes, but allows it to run with less resources. The complexity of NTFS increases features but requires more memory and processing power.

f0dder · « **Reply #15 on:** May 12, 2009, 12:46 AM »

4wd: the "especially suited for flash drives" of exFAT would be flash memory cards, not SSDs - and primarily because of things like being much simpler to implement than NTFS (digital cameras and other embedded devices are still relatively limited).

Kamel: you can't compare linux NTFS access speed to native speed... the only reliable NTFS support for linux is ntfs3g which is implemented in userland, and at least previous versions have been known to be pretty slow.

Bulk read/write of large files should be the same speed on nonfragmented FAT and NTFS drives. Lots of tiny modifications (creating small files or directories, manipulating dates/permissions etc) is where you'd be able to see a difference between FAT and NTFS - and I honestly don't know which one would have the speed advantage. NTFS needs to journal the fs metadata, which obviously takes some time, but on the other hand it uses smarter data structures, like not having to use the FAT hack of multiple fs entries for long filenames, and storing really small files directly in the MFT entries.

Iterating over the filesystem (search for files, whatever) should be faster on NTFS than FAT.

Kamel · « **Reply #16 on:** May 12, 2009, 04:47 PM »

Kamel: you can't compare linux NTFS access speed to native speed... the only reliable NTFS support for linux is ntfs3g which is implemented in userland, and at least previous versions have been known to be pretty slow.
-f0dder (May 12, 2009, 12:46 AM)

I am aware of this, and I did not compare speeds in linux alone. It is also important for you to understand that the drive was read from raw access, not by using a driver of any sort. (aka, no driver necessary)

yksyks · « **Reply #17 on:** June 22, 2009, 08:33 AM »

Just to inform how I solved the issue: The problem was not with the Acer Aspire One being slow, but there were unbearable delays every now and then. The PC stopped responding for a span from 30 seconds to 3 minutes. Also, while benchmarking the SDD (using the HD Tune), the results varied from 34 MB/s to notches of 0.1 MB/s, without any apparent pattern.

I browsed many forums about this issue, as I suspected the SSD or the controller to be failing, only to realize that this is a common problem. Some people reported significant improvement when using FlashPoint driver, as 4wd pointed out (thanks again!).

So I installed the latest beta and now I have a completely different machine! The benchmarks shows now a comb-like pattern varying from 34.3 MB/s to 30.8 MB/s. There are no delays at all! Of course, the machine has not a blazing speed like "big" notebooks with real hard disks, but that had to be expected.

At the moment there's only one small drawback—the current version of FlashPoint doesn't support hibernation.

Besides, I didn't notice any change in speed when using NTFS instead of supplied FAT32.

I don't know how the FlashPoint works, but it works really perfect. Kudos to the developers!

f0dder · « **Reply #18 on:** June 22, 2009, 11:08 AM »

I don't know how the FlashPoint works, but it works really perfect. Kudos to the developers!
-yksyks (June 22, 2009, 08:33 AM)

My guess is that it uses a filter driver to catch writes going to the flash drive, and imposes a delay on the writes so it has a chance to merge several smaller writes into fewer large ones - since small random writes are what kills performance on most of the flash drives around today. If the developers are smart, they will have gathered data on the write and erase block sizes of the drive, and try to do erase-block size aligned (and sized) writes.

4wd · « **Reply #19 on:** June 22, 2009, 02:46 PM »

My guess is that it uses a filter driver to catch writes going to the flash drive, and imposes a delay on the writes so it has a chance to merge several smaller writes into fewer large ones - since small random writes are what kills performance on most of the flash drives around today. If the developers are smart, they will have gathered data on the write and erase block sizes of the drive, and try to do erase-block size aligned (and sized) writes.
-f0dder (June 22, 2009, 11:08 AM)

Give that man a ceeeggaaarrr!

From the thread I posted earlier:

Basically, FlashPoint translates small random writes to big sequential writes with RAM buffer to get better write performance.

yksyks · « **Reply #20 on:** July 05, 2009, 04:23 PM »

Because FlashPoint was discussed here and because it turned my AAO from a useless toy to a quite usable device, here are some latest news:

We have stopped beta testing and distributing the software.
Hopefully, we will resume the distribution, soon!

Thank you.
-http://mydellmini.com/forum/dell-mini-9-discussion/5980-flashpoint-solid-state-drive-accelerator.html

The developer's site is not accessible anymore.

However, there's a mirror of part of the site: http://blog.ka-ki.ne.../04/flashpoint-note/

Or you can download the latest beta directly from http://rapidshare.co...flashpoint2009b6.zip

I can only recommend it, absolutely no problems so far. Enjoy it, but don't forget you can't use hibernation with beta 6.

4wd · « **Reply #21 on:** July 05, 2009, 08:06 PM »

The developer's site is not accessible anymore.
-yksyks (July 05, 2009, 04:23 PM)

It's due to a clash of names - there's already something available with the name FlashPoint.

So as soon as a new suitable name is chosen and possibly registered/trademarked/whatever the site will be back up.

There's a Yahoo Group where you can read what's happening: flashpointusers (sorry, haven't got a URL.)

You wouldn't have any more of the betas after 3 would you, (I like to keep up-to-date even though I don't use it) ?

Thanks for beta6.

yksyks · « **Reply #22 on:** July 05, 2009, 09:35 PM »

Thanks for an explanation. If it's not anything worse than a name collision... More info is here.

I also have beta4 here, but can't find the link anymore. I didn't try it though, I started directly with beta6 and I'm not going to touch it.

4wd · « **Reply #23 on:** July 20, 2009, 08:13 PM »

Flash~~Point~~Fire is back!

Hello, everyone!!

Finally, we are doing fresh restart with the new name, 'FlashFire'

FlashFire version 0.99 is now available here.
( http://tech.groups.y...ashpointusers/files/)

FlashFire 0.99 is functionally same with FlashPoint Beta 6 version, but now it has a installer.
In addition, it is only supports Windows XP.

Previous blog can be accessed with this address (http://zflashfire.blogspot.com), and you can leave feedback there.

Thank you.

Hyojun Kim

Deozaan · « **Reply #24 on:** July 14, 2010, 08:09 PM »

FlashFire has opened the source to become OpenFlashFire:

http://flashfire.org/xe/