Re: System on SSD
Hi, just some notes about the current state migrating to an SSD for the system. I installed the SSD, created a GPT partition on it that contains the following layout. a: 1 GB UFS b: 40 GB swap d: 8 GB HAMMER e: 10 GB unused Currently only swap is used by swapcache. That indeed speed up things like tab-completion, searching for files and build pkgsrc a lot. But I did not run an benchmarks or speed comparison tests. UFS should contain /boot and the rest of the system (/usr and /var) will go on the HAMMER filesystem. Any PFSs that are heavily modified will stay on another HDD. Before using the SSD for the system I tried migrating the system from an older and smaller HDD to a bigger one. I used the following steps, that are also described in [1] and the gpt man page. * partition the new disk * use cpdup to copy / * remove any links in /pfs via rm * run hammer mirror-copy /olddisk/pfs/usr /newdisk/pfs/usr to mirror /usr * do the same for var, var.tmp, ... * adjust HAMMER configuration of usr.obj, var.tmp, tmp by running hammer viconfig /pfs/usr.obj and set snapshots to 0d 0d to disable them completely * adjust /etc/fstab (mainly change the serial number of the disk :)) * run boot0cfg to make the new disk bootable That's all to copy the system. Most of the time is waiting for the mirror-copy command to finish. Sven [1] http://www.dragonflybsd.org/docs/howtos/howto_reinstall_hammer/
Re: System on SSD
On Tue, May 10, 2011 at 01:05:28PM -0700, Matthew Dillon wrote: :Hi, : :I just bought an 60 GB SSD (OCZ Vertex 2). I want :to use about 20 GB for swapcache. But I think about :putting the system also on this SSD. To reduce writes :I want to disable history keeping and mount the pfs :with noatime. I also want to move /usr/src and :/usr/pkgsrc and the build directories to a normal HDD. : :Are there any issues to keep in mind? Any suggestion? : :Thanks a lot. : :Sven Thanks a lot for the detailed explanation and hints below. This helped a lot. If you are going to run HAMMER on the SSD then you also have to manage the reblocking operation(s) on the PFSs. I would completely disable the 'recopy' function by commenting it out and I would adjust the reblocking parameters to spend 1 minute every 5 days instead of 5 minutes every 1 day. Everything else can be left as-is. You can also leave history enabled. nohistory will actually generate more write activity. Though you do have to be careful about the retention time due to the limited amount of space available on the SSD, so you might want to adjust the snapshot interval down from 60d to 10d or something like that. History is one of HAMMER's most important features, it is best to leave it on for all primary information storage. I usually turn it off only for things like /usr/obj. I think my description was not quite correct. I do not thought of using the nohistory mount option. Instead I wanted to configure the pfs to avoid storing the history like it is done for /usr/obj. I think it might not be necessary as the binaries are changed less frequently. Most of these parameters are controlled via 'hammer viconfig pfs'. You want to adjust the config for each mounted PFS and for '/'. -- In terms of layout you will want around a ~1G 'a' partition for /boot, which must be UFS, then I recommend a 32G 'b' swap partition and the remainder for a HAMMER 'd' partition. I usually leave ~4-8G unpartitioned (I setup a dummy 'e' partition that is 4-8G in size which is left unused), assuming a pristine SSD. You're right, it is a pristine SSD and I actually planned to leave 10 GB unused on it. My space consideration was similar but I have kept /boot smaller, maybe too small. -- In terms of putting the root filesystem on the SSD and not the HDD, I think it is reasonable to do and if you do you will almost certainly want to put any heavily modified subdirectories on the HDD. /usr/src, /usr/pkgsrc, possibly also /home and /usr/pkg, but it is up to you. That was also the idea, moving all frequently changing directories/pfs to a HDD. About 20 GB is also very small for the system, build directories and home. Usually it is easier just to use the SSD as your 'a' boot + 'b' swap and put your root on your HDD. You can use the remaining space on the SSD as an emergency 'd' root. The reason it is generally better to put the normal root on the HDD is that you don't have to worry about fine tuning the space and you don't have to worry about write activity. You can still use swapcache to cache a great deal of the stuff on the HDD onto the SSD via the swap partition on the SSD. Booting w/root on the HDD will be slightly slower but not unduly so, and once stuff gets cached on the SSD things get pretty snappy. -- Finally, i386 vs x86-64. If you are running a 32 bit kernel the maximum (default) swap space is 32G. With a 64 bit kernel the maximum is 512G. swapcache works very nicely either way but if you intend to run a 64 bit kernel you might want to consider configuring a larger swap space and essentially dedicating the SSD to just boot + swap. It depends a lot on how much information needs to be cached for all of the system's nominal operations. With swapcache you will universally want to cache meta-data. Caching file data depends on the situation. It is just my workstation. I'm just interested in trying swapcache and an SSD. I tried DragonFly mainly to use HAMMER to get a simple and easy backup solution using the mirror-stream command. So the next step is to get an idea of swapcache. But I thought 50 GB for swapcache on a workstation is wasted spaces on the SSD. That's why I wanted to put the system on the SSD too, to see if this will speed up things more. After reading this I think I will start with swapcache first and leave space for the system. Then put the system on the SSD and try to get some details if this speed up things more. Thanks a lot. Sven
System on SSD
Hi, I just bought an 60 GB SSD (OCZ Vertex 2). I want to use about 20 GB for swapcache. But I think about putting the system also on this SSD. To reduce writes I want to disable history keeping and mount the pfs with noatime. I also want to move /usr/src and /usr/pkgsrc and the build directories to a normal HDD. Are there any issues to keep in mind? Any suggestion? Thanks a lot. Sven
Re: System on SSD
On Dienstag, 10. Mai 2011 at 21:04, Sven Gaerner wrote: I also want to move /usr/src and /usr/pkgsrc and the build directories to a normal HDD. Why? Isn't this where a SSD really shines? (the pkgsrc tree doesn't matter much because it doesn't contain the actual source, but I think you really really want the work directories on the SSD) -matthiasr
Re: System on SSD
:Hi, : :I just bought an 60 GB SSD (OCZ Vertex 2). I want :to use about 20 GB for swapcache. But I think about :putting the system also on this SSD. To reduce writes :I want to disable history keeping and mount the pfs :with noatime. I also want to move /usr/src and :/usr/pkgsrc and the build directories to a normal HDD. : :Are there any issues to keep in mind? Any suggestion? : :Thanks a lot. : :Sven If you are going to run HAMMER on the SSD then you also have to manage the reblocking operation(s) on the PFSs. I would completely disable the 'recopy' function by commenting it out and I would adjust the reblocking parameters to spend 1 minute every 5 days instead of 5 minutes every 1 day. Everything else can be left as-is. You can also leave history enabled. nohistory will actually generate more write activity. Though you do have to be careful about the retention time due to the limited amount of space available on the SSD, so you might want to adjust the snapshot interval down from 60d to 10d or something like that. History is one of HAMMER's most important features, it is best to leave it on for all primary information storage. I usually turn it off only for things like /usr/obj. Most of these parameters are controlled via 'hammer viconfig pfs'. You want to adjust the config for each mounted PFS and for '/'. -- In terms of layout you will want around a ~1G 'a' partition for /boot, which must be UFS, then I recommend a 32G 'b' swap partition and the remainder for a HAMMER 'd' partition. I usually leave ~4-8G unpartitioned (I setup a dummy 'e' partition that is 4-8G in size which is left unused), assuming a pristine SSD. -- In terms of putting the root filesystem on the SSD and not the HDD, I think it is reasonable to do and if you do you will almost certainly want to put any heavily modified subdirectories on the HDD. /usr/src, /usr/pkgsrc, possibly also /home and /usr/pkg, but it is up to you. Usually it is easier just to use the SSD as your 'a' boot + 'b' swap and put your root on your HDD. You can use the remaining space on the SSD as an emergency 'd' root. The reason it is generally better to put the normal root on the HDD is that you don't have to worry about fine tuning the space and you don't have to worry about write activity. You can still use swapcache to cache a great deal of the stuff on the HDD onto the SSD via the swap partition on the SSD. Booting w/root on the HDD will be slightly slower but not unduly so, and once stuff gets cached on the SSD things get pretty snappy. -- Finally, i386 vs x86-64. If you are running a 32 bit kernel the maximum (default) swap space is 32G. With a 64 bit kernel the maximum is 512G. swapcache works very nicely either way but if you intend to run a 64 bit kernel you might want to consider configuring a larger swap space and essentially dedicating the SSD to just boot + swap. It depends a lot on how much information needs to be cached for all of the system's nominal operations. With swapcache you will universally want to cache meta-data. Caching file data depends on the situation. -Matt Matthew Dillon dil...@backplane.com
