HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

SSD's

 
SOLVED
Go to solution
Nobody's Hero
Valued Contributor

SSD's

I've been on this site for years, and have received so much knowledge and key learnings. just want to say thx to the long term expertise.

any who,

worked with hp systems 11 years, now in an hp/solaris environment.

Been testing solid state drives to improve the intense logging from sendmail. out of the box, no staggering iops or plain old, thats fast.

on the hook about 4k alignment for performance.
when uncompressing large files, the speed is minimal.

Am I missing something here? is the re-alignment of partitions necessary, or are these drives (flash SSD's) still doing alot of overhead with partitioning brain work?

Lost here...

10x
UNIX IS GOOD
3 REPLIES
Nobody's Hero
Valued Contributor

Re: SSD's

Oh and by thx, I mean, well by the size of the hat...
UNIX IS GOOD
Nobody's Hero
Valued Contributor
Matti_Kurkela
Honored Contributor
Solution

Re: SSD's

(Disclaimer: I haven't had a chance to see SSDs in action on HP-UX yet... although our first HP-UX filesystem migration to SSD will happen soonish so I've been reading about SSDs lately.)

SSDs are awesome on random reads, since compared to regular disks, the seek time simply does not exist.

Writing, especially writing small pieces of data sequentially one after another, is an Achilles' heel for SSDs. To write a line of text to a SSD, you must first read an entire SSD block, erase it, then re-write it with your change applied. If each mail log line is written as a separate synchronous operation, this will mean the SSD will be re-re-re-writing each block over and over many times. If an average sendmail log line is 200 bytes in length, that would mean about 20 rewrites for each 4k block.

If the filesystem block size is not equal to the SSD block size, this will also cause a further accumulation of re-writes. (If the filesystem uses 1k blocks but the SSD uses 4k, that's 4x the number of read/erase/rewrite cycles.)

When creating a HP-UX vxfs filesystem on a SSD, the most important thing is probably to match the filesystem block size to SSD block size. For 4k blocks:

mkfs -F vxfs -o bsize=4096 /dev/rdisk/diskNN

You'll also want plenty of write caching to ensure your write operations can be coalesced to 4k or bigger chunks, so that each SSD block will be written to only once or twice when writing data sequentially.

HP-UX uses LVM (or optionally VxVM) instead of partitions. LVM logical volumes are sized by extents, which are always 2^n MeB in size, so they should align well enough by default.

MK
MK