SSD Installation Considerations

Here you can post about non-standard installation methods
(for example when using grub4dos).
pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

SSD Installation Considerations

Post#1 by pizzar0 » 02 Aug 2011, 21:49

Since many appear to be still wondering about the ins-and-outs of SSDs and the important, general concepts of file(system) management under Linux, let a manufacturers take shed some light on the issue;
http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf
...and an other, more pictorial although probably less informative explanation
http://www.bswd.com/FMS09/FMS09-Sykes.pdf

Furthermore, for those who would be foolish enough and care to examine the intricacies of everything SSD/Flash, this link should provide a fair starting point, especially its reference section.
http://www.compuphase.com/mbr_fat.htm
Last edited by pizzar0 on 16 Aug 2011, 05:18, edited 2 times in total.

User avatar
francois
Contributor
Contributor
Posts: 5081
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: SSD Installation Considerations

Post#2 by francois » 03 Aug 2011, 16:28

Before downloading the pdf file, what is SSD? :unknown:
Voltaire: Le mieux est l'ennemi du bien.

User avatar
Hamza
Warlord
Warlord
Posts: 1847
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: SSD Installation Considerations

Post#3 by Hamza » 03 Aug 2011, 16:41

@francois,
More informations at Here

In some words, that is the SATA III
NjVFQzY2Rg==

User avatar
francois
Contributor
Contributor
Posts: 5081
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: SSD Installation Considerations

Post#4 by francois » 03 Aug 2011, 16:48

Straight answer. Thanks. :)
Voltaire: Le mieux est l'ennemi du bien.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: SSD Installation Considerations

Post#5 by Ahau » 03 Aug 2011, 18:47

Yep -- a good read. Very interesting for us as it relates to other flash media (CF, SD, etc., and USB flash drives). Since it's a powerpoint, most of the explanation must have been verbal in the presentation, so more detail would be useful. It seems NILFS performed very well in their tests. It has performed OK in mine (slower sustained writespeed than EXT4 or BTRFS, and a write speed for many small files that is much better than EXT4, but not quite as good as BTRFS).

Thanks for the link!
Please take a look at our online documentation, here. Suggestions are welcome!

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#6 by pizzar0 » 03 Aug 2011, 21:16

You're welcome.
What else would you like to know? :) (as a presenter, yours truly. -And of course the power point was due to the live presentation which, by itself, blows, of course...)

The best general advise under the circumstances would be, in the case of USB 2.0/3.0, is to
1) use renowned manufacturers (Patriot, Corsair, Mushkin) and those products with "future proof" (predictable) page and block layout;
2) Take the time to align/optimize the file system for a particular product (NAND matrix) including the boot sequence, page size etc.
One is likely to obtain 20-40% r/w performance gains from these steps alone which is likely more than could be attained due to file system differences.

About NILFS in very broad strokes;
NILFS is without peers on nseq. /w IFF its set up and used correctly which is virtually never the case! (1000/990 MB/s sustained r/w speed on a 16 channel bus.) ***NILFS was specifically designed with SSDs + speed in mind***, unlike any other file system!!
In plain English; If one would like to see Slackware boot into a full DE in <2.9 seconds and then perform general I/O in excess of 500 MB/s then it comes down to NILFS. (One will try to put something on Youtube shortly if Nippon TT allows it, that is, since they still own the rights.)

Other than that, in the case of properly configured USB 3.0 "sticks" - e.g. LBAs aligned, channel#/bus width (2n), etc. - they should easily provide 90 - 200 MB/s sustained r/w on ext2-4/xfs without the need of too much FS optimization. With NILFS >>500 MB/s is well within reach. (That's 500 Megabytes per second!)
The main issue for the moment is A) Correctly written/functioning drivers; B) Feeding the (correctly implemented) controllers - with close to a 2W/port and a tendency to melt.

On anything "quality" USB 2.0 - like Patriot or Corsair - NILFS can sustain >=50 MB/s r/w. Again, if its not happening then its definitely a configuration/controller issue.

In short, there are (usb 3.0) products scheduled for Q2 2012 which will provide 200-400 MB/s sustained r/w without much tinkering. Still, nothing will come even close to NILFS' performance in the foreseeable future but it does have its stability/usage issues when it comes to the average user. (The mainline version - kernel - is hugely different from the git.)

We just thought these were rather important points to ponder when designing/using a Live Distro. Cheers

p.s. All of which could bring one to a rather important question: What is Porteus about/for in its current incarnation when the I/O bottlenecks are, once again, rapidly disappearing??
Last edited by pizzar0 on 03 Aug 2011, 23:27, edited 1 time in total.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: SSD Installation Considerations

Post#7 by Ahau » 03 Aug 2011, 23:06

Excellent! I'll have to go over the .pdf and take some notes, and ask questions (if you'd be so kind to oblige!). Mainly, what I meant is that most users (of USB flash drives, SSD owners seem to be a little more educated), don't know many specifics about how flash works, so a lot of the information will be over their heads (some of it was over mine!) without more verbose explanation.

I like NILFS a lot. On my hardware (run of the mill Dell Core 2 Duo laptop, and a Kingston 8gb datatraveler DT101 G2, as well as an older Lexar Jumpdrive Twistturn 4gb), NILFS fails to match BTRFS for speed. I have my partitions aligned to eraseblock boundaries. What modifications can be done to improve the performance of NILFS? I've used the defaults for creating and mounting.

Also, does the circular log concept of NILFS provide any wear-leveling benefits to speak of, or is this driven primarily by the USB controller? In other words, is NILFS writing sequentially to physical pages on the drive and cycling through them, or is it merely writing to a logicalblock/sector, and the USB controller is free to map those logical blocks to the physical location of it's choosing, assuming the controller has some form of wear-leveling programmed in? My understanding of all this is still in its' infancy, but it seems to me that the latter would be the case.
Please take a look at our online documentation, here. Suggestions are welcome!

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#8 by pizzar0 » 04 Aug 2011, 02:25

What modifications can be done to improve the performance of NILFS?
Unfortunately the correct answer is:
A) There are numerous, potential modification (vs default) that are likely to impact the I/O performance;
B) Most of which is entirely vendor (NAND/Controller) dependent.
Example: Most people seem to confuse NAND flash cell size with NAND erase page size. Those are two different things since several cells make up a single erase page. The need is to align only the cell part, not the erase
page size. For example, on the Intel 320M series drives the erase page size is 256 cells -> 256*8192 == 2097152, or 2MBs. (If one could provide an ***accurate*** list for all the NAND flash cell sizes for all the drives out there, that person would become everybody's hero!)
Hence, unless one has access to the (hardware) specs of the Kingston 8gb datatraveler DT101 G2, specifically, no correct, general answer is possible. (Its not unlike developing wifi drivers for proprietary firmware - madwifi, etc..) One thing is for sure, though; Unless that Kingston is a uniquely screwed up, odd piece of flash drive NILFS should blow away BTRFS by about a country mile, in most cases.
assuming the controller has some form of wear-leveling programmed in? My understanding of all this is still in its' infancy, but it seems to me that the latter would be the case.
...and you'd be correct in that assumption.

Which is why the fundamental problem, at present, is that the I/O stacks in most OSs are much uncoupled from the manufacturers hw implementation and there are very few - if any - low level tools (in the OS itself) which would provide direct access those layers. Hence, one is very much at the manufacturers mercy and no file system modification alone could bridge that gap. (... which is why its rather important to be selective about manufacturers products and go with those who know what the hell they are doing, on average. (Corsair being one of those.. and No, I don't work for them.)

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: SSD Installation Considerations

Post#9 by Ahau » 04 Aug 2011, 05:35

Thanks, pizzar0!

If you haven't looked it up yet, check out the linaro flash card survey. They are working on defining and listing the specifications of various flash devices. They've developed a program called flashbench (for which I'll be writing a howto for porteus users), that times read/write access across the device to see what the page (aka cell) and erase block sizes are. Using that tool, along with the help of it's creator are how I know the characteristics of those two drives. You're absolutely right about being at the mercy of the manufacturers--they don't exactly go out of their way to publish this information. The kingston drive has a 16KB effective page size (could be a dual channel 8KB page size), with a 4MB effective eraseblock size. It can handle writing to 12 open eraseblocks at a time with linear writes, and 14 at a time with random writes, and the first 4MB block is optimized for a FAT table.

I do notice a speed boost in linear writes (10-12 MB/s) vs random writes (5-6 MB/s). It's almost like some filesystems take advantage of this, but nilfs isn't. NILFS was also a touch slower on the Lexar drive. I'll keep poking with nilfs to see if I can learn my way around it :)

thanks again!
Please take a look at our online documentation, here. Suggestions are welcome!

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#10 by pizzar0 » 04 Aug 2011, 12:15

"The kingston drive has a 16KB effective page size (could be a dual channel 8KB page size), with a 4MB effective eraseblock size"
... and there is your problem. that says absolutely nothing about the cell size (how many cells / page??) or the controllers queuing method. Once again the eraseblock size isnt relevant because one has to align the file system to the NAND cells themselves.
Of course, if the manufacturers published their specs. - and very few do - this whole topic would become rather mute.
Modern file systems are reasonably flexible but there is only so much they can do to overcome implementation screw-ups. (You get what you pay for! - And in the case of flash drives it never ceases to amaze how people keep buying garbage then expect performance out of it, especially since the price differences are rather negligible between junk and high-performance. Then again, most select flash drives based on whether its "cute" and if it "has a nice cap chain".)

Here is a real life example of what happens when manufacturers "go bad".
2009-2010; Super Talent - Pico series; (We had these OEM from them in lots of 2k-4k.)
October 2009 -> 8 GB STM8GPCS 00412B rev.5 comes out;
Fastest USB 2.0 drive on the planet, beating the big names hands down.
Read/Write -> 36 / 28 MB/s
... forward 9 months ....
June 2010 -> 8 GB - STU8GPCS 005102 rev.1 replaces previous line;
Read/Write -> 21 / 12 MB/s
...
July 2010 -> 8 GB - STE8GPCF 00110204 is added to the line up;
Read/Write -> 17 / 9 MB/s

E.g. No matter how much lipstick is put on a pig, a pig is still a pig.
I do notice a speed boost in linear writes (10-12 MB/s) vs random writes (5-6 MB/s). It's almost like some filesystems take advantage of this, but nilfs isn't. NILFS was also a touch slower on the Lexar drive.
Those are terrible performance numbers. (Linear writes should inherently increase the speed because that the nature of the beast). Lexar flash drives are garbage, from experience, and Kingston... I don't know how but your numbers are less than spectacular.

Ultimately, when performance matters the first thing to do is to get a product where it (or at least the potential thereof) is designed in by the manufacturer. (I hate to tell you this but the project you mentioned is less likely to succeed - I could be wrong, though - simply because as the dye size shrinks the a hw implementations change faster than a pregnant womans breakfast preference.) -Corsair, Patriot, Mushkin will rarely disappoint but any company which optimizes to the initial allocation blocks for FAT is obviously targeting Joe Blow who will never pause to care as he saves his Word documents under Windows.
===
Here are some "common usage" numbers - USB 2; NILFS - all averaged over time; sustained r/w:
Read | Write [in MB/s]
Patriot XTransporter [8GB] 34 27
Corsair Voyager [8GB] 32 27
Mushkinf Enhanced [8GB] 34 28
Patriot Rage XT [16GB] 46 34 -> what a difference the controller makes! Bigger should = Slower but not here.
Corsair Voyager [16GB] 46 33 -> same holds as above
Last edited by pizzar0 on 05 Aug 2011, 13:53, edited 2 times in total.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: SSD Installation Considerations

Post#11 by Ahau » 04 Aug 2011, 15:25

Thanks, once again, pizzar0!

Yes, I know my Kingston's performance isn't great -- I bought it before I knew what I know now. It had reviewed well and was cheap ;) I'll definitely keep Corsair, Patriot, and Mushkin in mind for future purchases (I've always had an interest in Mushkin for some reason, though never bought any of their products). The good news is that the audience for my documentation (straying from the topic at hand for a bit, sorry!) is mostly joe-blows when it comes to buying flash drives and using them with Porteus. Those who are experts already will probably have little to gain from my rambling drivel.

Thanks also for posting the second PDF -- that one gets to a lot of the issues with flash devices (round hole, square peg with regards to OS's and FS's).

RE: NILFS, maybe I'll try compiling the latest from GIT (hopefully I can compile it against the standard porteus kernel and replace the existing driver, rather than patching and recompiling the whole kernel). I should compile the userland tools while I'm at it -- I think I converted them from a .deb I found. I won't be recommending it for general use until it is more stable and has an fsck function, but I'll definitely be doing some stuff with it in our 'unsupported software' section -- namely, using it as a filesystem for save.dat containers.

RE: the Linaro Flash Card Survey -- I shouldn't speak too much on their behalf, but I believe the goal is not to catalogue each and every flash device. Rather, it is to gain a broader understanding of the hardware that is out there, and then optimize their kernel, OS and FS to handle flash devices better. To that end, I think they can have more success, but you're correct about how quickly the technology changes. So, hopefully their optimizations will be flexible to change with the hardware.

RE: page size/eraseblock size -- I agree that aligning to pages is of primary importance. I did notice faster write speeds in some tests when my drive was aligned on a 4MB multiple vs a 4MB multiple +1MB. I ran each test three times and took the average of the three tests and calculated the standard deviation and coefficient of variation. Though 4MB often scored higher, it primarily did so by less than the coefficient of variation (except for one test that was a little bit more conclusive). Since every page size I've seen can be divided into 1MB, I'll primarily be urging users to align the start of their partitions to a sector that is divisible by 2048. This is likely not perfect, but far better than starting on sector 63 or 'wherever-the-hell-gparted-decides-to-put-it'.

Back to the first .pdf you posted, here are some of my questions related to the slideshow:

In the I/O statistics (1/2), what are we looking at here? Is NILFS so consistently high because of how it writes once and retains old files on disk, and is scoring high in this measure good, bad, or indifferent based on the inherent differences between FS's?

I/O statistics 2/2 -- again, what are we looking at here? Whether or not the FS places data in order, based on the order received?

Case study -ext4 -- what's the ext4-wb stand for?

Case study - btrfs -- I haven't tried it with larger block sizes, but this lines up with some of my experience -- I noticed small performance gains with SSD option (ssd_spread, in my case) and, I tested FAT with the default cluster size and with a 16KB cluster size. The larger cluster size wasted lots of space (~20%) for small files, was slower with small files, and just a tad faster with larger files. Not really worth it.

Case study -xfs -- I got some gains with XFS with barriers disabled, but it still didn't improve it's performance with small files to the point where it came even close to EXT4, BTRFS, or NILFS. Perhaps the effect is exaggerated when you are operating with more channels?

All I have to say about TRIM is that I wish they had it in flash drives, so I could play with it :)


Again, thank you for all of your helpful information and responses. I could probably go on badgering you with questions all day, but I'll stop here and look for more resources on the web :)

Posted after 31 minute 45 seconds:
Ok -- rereading the mkfs.nilfs2 man page with a little deeper perspective, I can see where I've not aligned it optimally for my device. It defaults to a 4096 page size and an 8MB allocation unit size. I'm dealing with a 16kb page size (or so I believe) and a 4MB allocation unit size (that one is easier for me to see in the flashbench tests). This is starting to get fun!
Please take a look at our online documentation, here. Suggestions are welcome!

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#12 by pizzar0 » 04 Aug 2011, 19:55

Hey, no sweat!

I'll primarily be urging users to align the start of their partitions to a sector that is divisible by 2048. This is likely not perfect, but far better than starting on sector 63 or 'wherever-the-hell-gparted-decides-to-put-it'.
Its a good start. I would recommend to also consider what the first 4-8MB is used for
by the micro controller. To leave those initial allocation units alone is never a bad idea.

Probably the most useful advice you could give to average users is to FIRST EXAMINE the manufactrurers original formating (FAT) because they will have that optimized for their specific implementation. (They want to impress you right-out-of-the-box... if they can. :-) That will hold at least some clues.

...
the Linaro Flash Card Survey
I understand their intentions and it is a good one. The problem as I see it for the moment is that manufacturers change their specs. faster than you can read their outline. It will get better, though... eventually. Plus you have to remember that there is a yet to be decided battle raging out there as in SCSI vs. USB 3.0. (USB 3 should win with ease! -Just compare the power requirements which is the decisive factor at the end of the day. Then again it puts the burden of added comlexity squarely on the manufacturers who might not like it, etc.. etc...)

...
Though 4MB often scored higher, it primarily did so by less than the coefficient of variation.
No surprise there. Have you tried 8MB starting at LBA 16384 as we suggested??
Also, what if the erease blocks were !=2^n ?? in which case 3MB is the better choice, less common as it may be.

...
In the I/O statistics (1/2), what are we looking at here? Is NILFS so consistently high because ...
Yes and Yes, as in: its good in general because it shifts the work load away from the controller onto the CPU.

...
I/O statistics 2/2 -- again, what are we looking at here?
It is a comparison how effectively each filesystem combines data before writing to the I/O bus. (The less the better - larger columns in the graph. -Unless it occasionally and suddenly jams the controller's pipeline... nilfs.)
...
what's the ext4-wb stand for?
write-back

...
btrfs -- ... The larger cluster size wasted lots of space (~20%) for small files, was slower with small files, and just a tad faster with larger files. Not really worth it.
I agree.

...
xfs -- I got some gains with XFS with barriers disabled, but it still didn't improve it's performance with small files to the point where it came even close to EXT4, BTRFS, or NILFS.
Perhaps the effect is exaggerated when you are operating with more channels?
Well, then something was wrong there because;
A) W/O barriers xfs should be naturally (much) faster;
B) On a multi-channel bus/IO xfs will still run one big circle around ext4, even on a cloudy day. (Did you set an external log(!!) and what was the logbuf size and agcount on what size device?)
...
All I have to say about TRIM is that I wish they had it in flash drives, so I could play with it
Unfortunatelly Linux has no clue about TRIM, or anything related, and until someone writes it and puts it into the the kernel...
Cheers

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#13 by pizzar0 » 04 Aug 2011, 19:55

Hey, no sweat!

I'll primarily be urging users to align the start of their partitions to a sector that is divisible by 2048. This is likely not perfect, but far better than starting on sector 63 or 'wherever-the-hell-gparted-decides-to-put-it'.
Its a good start. I would recommend to also consider what the first 4-8MB is used for
by the micro controller. To leave those initial allocation units alone is never a bad idea.

Probably the most useful advice you could give to average users is to FIRST EXAMINE the manufactrurers original formating (FAT) because they will have that optimized for their specific implementation. (They want to impress you right-out-of-the-box... if they can. :-) That will hold at least some clues.

...
the Linaro Flash Card Survey
I understand their intentions and it is a good one. The problem as I see it for the moment is that manufacturers change their specs. faster than you can read their outline. It will get better, though... eventually. Plus you have to remember that there is a yet to be decided battle raging out there as in SCSI vs. USB 3.0. (USB 3 should win with ease! -Just compare the power requirements which is the decisive factor at the end of the day. Then again it puts the burden of added comlexity squarely on the manufacturers who might not like it, etc.. etc...)

...
Though 4MB often scored higher, it primarily did so by less than the coefficient of variation.
No surprise there. Have you tried 8MB starting at LBA 16384 as we suggested??
Also, what if the erease blocks were !=2^n ?? in which case 3MB is the better choice, less common as it may be.

...
In the I/O statistics (1/2), what are we looking at here? Is NILFS so consistently high because ...
Yes and Yes, as in: its good in general because it shifts the work load away from the controller onto the CPU.

...
I/O statistics 2/2 -- again, what are we looking at here?
It is a comparison how effectively each filesystem combines data before writing to the I/O bus. (The less the better - larger columns in the graph. -Unless, of course, when on occasion it suddenly jams the controller's pipeline... nilfs.:-)
...
what's the ext4-wb stand for?
write-back

...
btrfs -- ... The larger cluster size wasted lots of space (~20%) for small files, was slower with small files, and just a tad faster with larger files. Not really worth it.
I agree.

...
xfs -- I got some gains with XFS with barriers disabled, but it still didn't improve it's performance with small files to the point where it came even close to EXT4, BTRFS, or NILFS.
Perhaps the effect is exaggerated when you are operating with more channels?
Well, then something was wrong there because;
A) W/O barriers xfs should be naturally (much) faster;
B) On a multi-channel bus/IO xfs will still run one big circle around ext4, even on a cloudy day. (Did you set an external log(!!) and what was the logbuf size and agcount on what size device?)
...
All I have to say about TRIM is that I wish they had it in flash drives, so I could play with it
Unfortunatelly Linux has no clue about TRIM, or anything related, and until someone writes it and puts it into the the kernel...
Cheers

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: SSD Installation Considerations

Post#14 by Ahau » 04 Aug 2011, 21:53

My previous post seems to be lost in limbo, perhaps with pizzar0's duplicated over the top of it. Here is what I had written:

Thanks, once again, pizzar0!

Yes, I know my Kingston's performance isn't great -- I bought it before I knew what I know now. It had reviewed well and was cheap I'll definitely keep Corsair, Patriot, and Mushkin in mind for future purchases (I've always had an interest in Mushkin for some reason, though never bought any of their products). The good news is that the audience for my documentation (straying from the topic at hand for a bit, sorry!) is mostly joe-blows when it comes to buying flash drives and using them with Porteus. Those who are experts already will probably have little to gain from my rambling drivel.

Thanks also for posting the second PDF -- that one gets to a lot of the issues with flash devices (round hole, square peg with regards to OS's and FS's).

RE: NILFS, maybe I'll try compiling the latest from GIT (hopefully I can compile it against the standard porteus kernel and replace the existing driver, rather than patching and recompiling the whole kernel). I should compile the userland tools while I'm at it -- I think I converted them from a .deb I found. I won't be recommending it for general use until it is more stable and has an fsck function, but I'll definitely be doing some stuff with it in our 'unsupported software' section -- namely, using it as a filesystem for save.dat containers.

RE: the Linaro Flash Card Survey -- I shouldn't speak too much on their behalf, but I believe the goal is not to catalogue each and every flash device. Rather, it is to gain a broader understanding of the hardware that is out there, and then optimize their kernel, OS and FS to handle flash devices better. To that end, I think they can have more success, but you're correct about how quickly the technology changes. So, hopefully their optimizations will be flexible to change with the hardware.

RE: page size/eraseblock size -- I agree that aligning to pages is of primary importance. I did notice faster write speeds in some tests when my drive was aligned on a 4MB multiple vs a 4MB multiple +1MB. I ran each test three times and took the average of the three tests and calculated the standard deviation and coefficient of variation. Though 4MB often scored higher, it primarily did so by less than the coefficient of variation (except for one test that was a little bit more conclusive). Since every page size I've seen can be divided into 1MB, I'll primarily be urging users to align the start of their partitions to a sector that is divisible by 2048. This is likely not perfect, but far better than starting on sector 63 or 'wherever-the-hell-gparted-decides-to-put-it'.

Back to the first .pdf you posted, here are some of my questions related to the slideshow:

In the I/O statistics (1/2), what are we looking at here? Is NILFS so consistently high because of how it writes once and retains old files on disk, and is scoring high in this measure good, bad, or indifferent based on the inherent differences between FS's?

I/O statistics 2/2 -- again, what are we looking at here? Whether or not the FS places data in order, based on the order received?

Case study -ext4 -- what's the ext4-wb stand for?

Case study - btrfs -- I haven't tried it with larger block sizes, but this lines up with some of my experience -- I noticed small performance gains with SSD option (ssd_spread, in my case) and, I tested FAT with the default cluster size and with a 16KB cluster size. The larger cluster size wasted lots of space (~20%) for small files, was slower with small files, and just a tad faster with larger files. Not really worth it.

Case study -xfs -- I got some gains with XFS with barriers disabled, but it still didn't improve it's performance with small files to the point where it came even close to EXT4, BTRFS, or NILFS. Perhaps the effect is exaggerated when you are operating with more channels?

All I have to say about TRIM is that I wish they had it in flash drives, so I could play with it


Again, thank you for all of your helpful information and responses. I could probably go on badgering you with questions all day, but I'll stop here and look for more resources on the web

Posted after 31 minute 45 seconds:
Ok -- rereading the mkfs.nilfs2 man page with a little deeper perspective, I can see where I've not aligned it optimally for my device. It defaults to a 4096 page size and an 8MB allocation unit size. I'm dealing with a 16kb page size (or so I believe) and a 4MB allocation unit size (that one is easier for me to see in the flashbench tests). This is starting to get fun!
Please take a look at our online documentation, here. Suggestions are welcome!

pizzar0
White ninja
White ninja
Posts: 28
Joined: 08 May 2011, 22:26
Location: Chritmas Island

Re: SSD Installation Considerations

Post#15 by pizzar0 » 04 Aug 2011, 22:23

My previous post seems to be lost in limbo, perhaps with pizzar0's duplicated over the top of it. Here is what I had written:
That is entirely possible - even likely! - that I screwed up Ahau's earlier post. My apologies Ahau!!

Post Reply