# SSDs and swap files?



## Deleted member 2077 (Apr 20, 2012)

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?


----------



## wblock@ (Apr 20, 2012)

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.


----------



## Deleted member 2077 (Apr 22, 2012)

*T*hanks 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.



Anyone howtos or guides on how to do this?


----------



## wblock@ (Apr 22, 2012)

Disk Setup On FreeBSD


----------



## throAU (Apr 23, 2012)

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.



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.


----------



## UNIXgod (Apr 23, 2012)

If you have a lot of RAM tmpfs(5) is great for /usr/ports/etc/distfiles as well. You'll also want to investigate setting up trim.


----------



## wblock@ (Apr 23, 2012)

throAU said:
			
		

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



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.



Yes: PR bin/161720


----------



## throAU (Apr 24, 2012)

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.


----------



## Deleted member 2077 (Apr 25, 2012)

wblock@ said:
			
		

> Disk Setup On FreeBSD



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:


```
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)
```


----------



## wblock@ (Apr 25, 2012)

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.


----------



## Deleted member 2077 (Apr 25, 2012)

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



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

```
/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?


----------



## wblock@ (Apr 26, 2012)

It's an option to newfs(8) and tunefs(8).


----------



## bbzz (Apr 26, 2012)

wblock@ said:
			
		

> It's an option to newfs(8) and tunefs(8).



Does the *-t* switch in newfs(8) work even after the disk is used for ZFS?


----------



## wblock@ (Apr 26, 2012)

bbzz said:
			
		

> Does the *-t* switch in newfs(8) work even after the disk is used for ZFS?



Sorry, no idea.


----------



## kpa (Apr 26, 2012)

The man page of newfs(8) states:


```
-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.


----------



## throAU (Apr 27, 2012)

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.



I guess you could fudge this by swapping to a FILE on your filesystem?


----------



## wblock@ (Apr 27, 2012)

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.


----------

