another SSD partitioning thread....

I'm kind of new to FreeBSD, and *nix in general. I'm using it on an X200 Thinkpad and it's great, everything just works.


I bought a 32GB Corsair SSD just for FreeBSD, but was made aware of this whole partition alignment thing. It seems like a lot of trouble. Not sure if I should just stick with a platter drive for now.

I wanted to know...during sysinstall I just use the whole disk. At the part where I specify I guess the 'logical' partition GB for /, swap, /var, /tmp, /usr. Would these be "unaligned". Sorry if it's a dumb question.

Thanks :(
 
The partition (/dev/disk0s1 or whatever)? That is the slice. Take care of this with the 'Fdisk' option; there you basically slice your disk.

It is after this that you (after being asked about the bootloader) will partition the slice. It can have eight partitions (seven, to be specific).

To be succinct (basic order in a standard installation; I use my setup as example):

Fdisk (THIS is where you tell what space or slice you want to set up):
Code:
/dev/ad4s1      165     FreeBSD
...

Bootloader (up to you; take care)

Label (THIS is where you set up):
Code:
Part            MtPt
----            ----
ad4s1a          /
ad4s1b          swap
ad4s1d          /var
ad4s1e          /tmp
ad4s1f          /usr

Do not try to use /dev/disk0s1c (FreeBSD makes that the entire disk)
 
The problem with SSDs is the same as with "advanced format" drives. They use 4K or larger blocks but lie about it, pretending to use 512-byte blocks. For performance, partitions should be aligned to land on an even multiple of the block size. See The New Alternate Method: gpart(8) in Disk Setup On FreeBSD. That's untested by me because I've avoided such drives so far.

Since you don't have anything on the SSD, it's an opportunity to test performance. First, set it up the standard way, which should produce an un-aligned setup and give relatively poor performance. Benchmark it with something thorough, like benchmarks/bonnie++. Then repartition with gpart aligned to a multiple of the blocksize, install onto those partitions, and test again.

There's also TRIM. See
% man tunefs | less -p TRIM
 
So pretty much I can't use sysinstall. :\

Restoring stuff from an existing install however, like in your link, doesn't seem as daunting. I have another machine with FreeBSD in a VM, would that help?


1) Install the bad way
2) Benchmark with said tool
3) Dump directories & save on a flash drive
4) Remove & wipe SSD
5) Connect to other machine
6) gpart & restore directories in VM
7) Put SSD back in laptop
8) Profit?
 
dbsd said:
So pretty much I cant use sysinstall. :\

You can use sysinstall as long as you don't let it do the partitioning. It should show existing partitions, and you just enter the mountpoints for them. (I think that works for gpart but can't recall trying it.)

Restoring stuff from an existing install however, like in your link, doesnt seem as daunting. I have another machine with FreeBSD in a VM, would that help?

It might, if you want to restore backups from it to the SSD. Boot with a livefs CD/USB or mfsBSD to set up the partitions on the SSD. Then restore a FreeBSD system to those partitions. You can do that over SSH as in Backup Options For FreeBSD and should not need to physically move the SSD from one system to another.
 
wblock said:
You can use sysinstall as long as you don't let it do the partitioning. It should show existing partitions, and you just enter the mountpoints for them. (I think that works for gpart but can't recall trying it.)

OK that is good! For some reason - I thought by using gpart, you would have to do a manual install or something.
 
Ok so I've burned (wasted) lots of livefs discs. For some reason, I get into fixit on VMware fine with the ISO. When I put it to physical media and try it on my laptop, no dice. So I got an old 20GB Playstation drive and a USB enclosure, and made it a "rescue install" drive.

It boots up fine, and I follow the steps in the link:

[CMD=""]sysctl kern.geom.debugflags=16[/CMD]

Corsair drive is ad4:
[CMD=""]gpart create -s gpt /dev/ad4[/CMD]

Boot Partition:
[CMD=""]gpart add -l ssdboot -t freebsd-boot -s 16 ad4[/CMD]

Bootcode:
[CMD=""]gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ad4[/CMD]

And I get:
Code:
"gpart: /dev/ad4p1: No such file or directory"

This shows that it has been created:
[CMD=""]gpart show ad4[/CMD]

And I can see it /dev/ad4p1.

What could be the problem? :\
 
It would be good to see the output from the create and add steps. You might have to use the destroy command through gpart(8), or use dd(1) to wipe the first few blocks of the disk. And maybe the last few, too.
 
Nevermind. I got into Fixit on another machine and the problem's gone.

My new problem however, is that neither /boot/pmbr or /boot/gptboot exist. At least on the live CD.

I've seen /boot/boot0 used for the -b option. What about -p? Is it needed? :\
 
dbsd said:
Nevermind. I got into Fixit on another machine and the problem's gone.

My new problem however, is that neither /boot/pmbr or /boot/gptboot exist. At least on the live CD.

Are you using an old live CD? /boot/gptboot is on the 8.2 memstick image, should be on the CD also.

I've seen /boot/boot0 used for the -b option. What about -p? Is it needed? :\

You might be able to use only -b or only -p, I have not experimented. It works as shown on a USB hard disk.
 
Well, I guess did it.

I wasn't successful with sysinstall, after gpart. So I tried restoring another install onto the drive. It boots fine, just had to change my /etc/fstab.

Unfortunately, I do not have the "pre-alignment" bonnie++ output. I couldn't find my thumbdrive, so I jotted stuff down. I dont notice anything dramatically different, some numbers were even worse. But overall, it performs a little better:

Code:
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine       Siz  K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
	      4G   504   99  12082  2   12139  2   869  97 91522  11  4542  66
Latency             16757us     473ms    2608ms   88881us   51204us     181ms

Version  1.96       ------Sequential Create------ --------Random Create--------
	           -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
             files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
              16    4296  12 +++++ +++  8590  18  4715  12 +++++ +++  7991  17
Latency              7575us      25us     217us    5491us      21us   96033us


Boot time is insane, nonetheless! :e


My scheme is the following:
Code:
=>      34  62531116  ad4  GPT  (30G)
        34      1886       - free -  (943K)
      1920       128    1  freebsd-boot  (64K)
      2048  58720256    2  freebsd-ufs  (28G)
  58722304   3808846    3  freebsd-swap  (1.8G)

I went with a single / partition, for my laptop. And I made a 64K boot partition, instead of 8K. But my first (only) UFS does start on the 2048 (1MB) mark, and is an even GB amount. My remaining space being swap.


Did I do it right? Am I okay to start compiling Xorg, Fluxbox, and stuff?
 
An SSD should not take as big a performance hit from misalignment as a hard drive. For me, I'd back it up and go. If the partitioning is off, it can always be redone and then the backup restored.

Edit: for comparison, here's a decent drive (Caviar Black 1T) on a reasonably fast system (E8400):
Code:
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
lightning        4G   528  99 120238  15 51529  10  1045  99 127942  15 229.1   2
Latency             15739us   62396us     248ms   15615us   40816us     383ms
Version  1.96       ------Sequential Create------ --------Random Create--------
lightning           -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2436   7 +++++ +++  4783  10  2555   6 +++++ +++  4773  10
Latency               325ms      11us    1927us    4706us      20us    1046us
 
But is it off?


His first real partition starts on 2048, they are "whole numbers", and his final is not. So far so good, compared to mine.

Code:
=>      34  15663037  da0  GPT  (7.5G)
        34      1998       - free -  (999K)
      2032        16    1  freebsd-boot  (8.0K)
      2048   2097152    2  freebsd-ufs  (1.0G)
   2099200   2097152    3  freebsd-swap  (1.0G)
   4196352   2097152    4  freebsd-ufs  (1.0G)
   6293504   2097152    5  freebsd-ufs  (1.0G)
   8390656   7272415    6  freebsd-ufs  (3.5G)


BUT his final one is evenly divisible by 4096 bytes or 4K. Which is the overall point right?

"Leaving the -s size option off the last uses the rest of the disk. As long as these are even sizes in M or G, the alignment will remain correct."


I did this for my final one, swap in my case, and it came out to 1.8G - does this throw me off? It is not divisible.
 
It's not the size of the partition but where it starts that needs to be aligned on an even block. Only the last block would not be an exact multiple, and that's going to be written so rarely that it won't matter. An SSD probably uses blocks larger than 4K anyway, but they still ought to divide evenly into 1M.

I don't know what to make of your results. Random seeks being twenty times faster than the hard drive is reasonable, but I'd expect sequential read to be a lot faster.
 
Great, thanks.

Code:
ad4
	512                    # sectorsize
	32015965696 	       # mediasize in bytes (30G)
	62531183    	       # mediasize in sectors
	0           	       # stripesize
	0           	       # stripeoffset
	62034       	       # Cylinders according to firmware.
	16          	       # Heads according to firmware.
	63          	       # Sectors according to firmware.
	10476545990010200038   # Disk ident.
 
Back
Top