SSDs and swap files?

  • Thread starter Deleted member 2077
  • Start date
D

Deleted member 2077

Guest
Any suggestions on how to partition this? It'll be FreeBSD i386 9.0

Both drives are SATA II (3 Gbps):

SSD: 80G (intel 330 if it matter)
HDD: 2TB (segate green drive).

I want to put root/boot on SSD for quick startup times. The 2TB [give or take] is for data storage.

Is it advisable to put swap on SSD drive? If so, how much? (system will have 4 GB which is overkill; this server has low memory requirements, just runs standard unix services, no webserver or mail).

What about /tmp and /var, should those go on SSD or HDD? Does it matter either way?

I'll set trim in bsdinstall, but is there anything else that I need to do special for SSD?
 
I would put swap on the SSD, yes, although with the limited space and plenty of RAM, would keep it relatively small. tmpfs(5) works well for /tmp on a single-user desktop machine. It is not recommended for servers. /var likely does not need to go on the SSD.

Other stuff: make sure the SSD partitions are aligned to 4K blocks. bsdinstall(8) does not do that, so it means running gpart(8) by hand. That also lets you start the root filesystem partition at 1M.
 
Thanks for the tips.

wblock@ said:
Other stuff: make sure the SSD partitions are aligned to 4K blocks. bsdinstall(8) does not do that, so it means running gpart(8) by hand. That also lets you start the root filesystem partition at 1M.
Click to expand...

Anyone howtos or guides on how to do this?
 
wblock@ said:
Other stuff: make sure the SSD partitions are aligned to 4K blocks. bsdinstall(8) does not do that, so it means running gpart(8) by hand. That also lets you start the root filesystem partition at 1M.
Click to expand...

Question: is there any reason the installer does not do that by default? Simply because it never used to be relevant?

It's 4k of space we're talking about per partition, tops; would it not be prudent modify the installer to just align everything at 4k by default (user manually able to over-ride) these days irrespective of whether or not the disk uses 4k alignment or not?

On a disk of few hundred gigs (hell, even a few hundred MEG) or more, I'm sure users would be willing to take the capacity hit "just in case" these days, whether or not their disk needs it or not.
 
throAU said:
Question: is there any reason the installer does not do that by default? Simply because it never used to be relevant?
Click to expand...

Probably.

It's 4k of space we're talking about per partition, tops; would it not be prudent modify the installer to just align everything at 4k by default (user manually able to over-ride) these days irrespective of whether or not the disk uses 4k alignment or not?

On a disk of few hundred gigs (hell, even a few hundred MEG) or more, I'm sure users would be willing to take the capacity hit "just in case" these days, whether or not their disk needs it or not.
Click to expand...

Yes: PR bin/161720
 
Cheers for the heads up. I'm guessing it might be a good idea to explicitly request the option in setup (with a sane default pre-selected like 4k) for things like RAID5s (on a hardware controller) with 64k or larger stripe size?

I know you CAN manually do this already, but given the performance problems that can arise from mis-aligned partitions it will perhaps prevent some from installing FreeBSD, noticing that performance sucks on their misaligned setup, and giving up (without realizing why).

Before reading a lot recently on storage (although I've been using *nix for 15 years or so, it's previously never been in IO intensive situations and on 512 byte sector drives), I'd never really considered alignment of partitions during setup - having a prominent option with a "if you don't know, leave at default" box would at least get people to consider it.

2c.
 
wblock@ said:
Disk Setup On FreeBSD
Click to expand...

Thanks for the write up! :) I now have it installed on an SSD drive. How do I verify it is set up correctly? This is what gpart says:

Code: 
myhost# gpart show -lp
=>       34  156301421    ada0  GPT  (74G)
         34        256  ada0p1  gpboot  (128k)
        290       1758          - free -  (879k)
       2048  153092096  ada0p2  gprootfs  (73G)
  153094144    3207311  ada0p3  gpswap  (1.5G)
 
Scientifically speaking, the way to tell the difference would be to test it both nonaligned and aligned. There should be a clear improvement with 4K alignment.

That layout looks okay. It starts at an even boundary and is an even multiple of 4K.

diskinfo -tv /dev/ada0 gives a quick best-case benchmark, which might be comparable to the vendor-claimed speed of the SSD. Try benchmarks/bonnie++ for something relevant to the real world.
 
Thanks. It seems ok, it's an Intel 320 SSD (80 gigs) and claims this:

Sustained Sequential Read: Up to 270 MB/s
Sustained Sequential Write: Up to 90 MB/s
Click to expand...

I'm doing a build world on it with this diskinfo command, so seems reasonable

ada0: <INTEL SSDSA2CW080G3 4PC10362> ATA-8 SATA 2.x device
Code: 
/dev/ada0
        512             # sectorsize
        80026361856     # mediasize in bytes (74G)
        156301488       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        155061          # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        CVPR147103DR080BGN      # Disk ident.

Seek times:
        Full stroke:      250 iter in   0.020934 sec =    0.084 msec
        Half stroke:      250 iter in   0.022523 sec =    0.090 msec
        Quarter stroke:   500 iter in   0.048168 sec =    0.096 msec
        Short forward:    400 iter in   0.038257 sec =    0.096 msec
        Short backward:   400 iter in   0.038224 sec =    0.096 msec
        Seq outer:       2048 iter in   0.190736 sec =    0.093 msec
        Seq inner:       2048 iter in   0.176223 sec =    0.086 msec
Transfer rates:
        outside:       102400 kbytes in   0.465104 sec =   220166 kbytes/sec
        middle:        102400 kbytes in   0.461481 sec =   221894 kbytes/sec
        inside:        102400 kbytes in   0.462394 sec =   221456 kbytes/sec


One last question, how do I set trim on this or does it do it automatically?
 
The man page of newfs(8) states:

Code: 
 -t      Turn on the TRIM enable flag.  If enabled, and if the underlying
             device supports the BIO_DELETE command, the file system will send
             a delete request to the underlying device for each freed block.


"For each freed block" implies that the TRIM functionality is limited to blocks that are managed by a UFS filesystem.

This means that the swap subsystem and other filesystems would need to implement their own TRIM functionality if they don't have one.
 
kpa said:
"For each freed block" implies that the TRIM functionality is limited to blocks that are managed by a UFS filesystem.

This means that the swap subsystem and other filesystems would need to implement their own TRIM functionality if they don't have one.
Click to expand...

I guess you could fudge this by swapping to a FILE on your filesystem?
 
That's an interesting idea. Filesystem overhead is probably not going to be much on an SSD. Also a lot easier to change the size of a swap file than a swap partition.
 
You must log in or register to reply here.
Back
Top