System on SSD

2011-05-10 Thread Sven Gaerner
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

2011-05-10 Thread Matthias Rampke
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

2011-05-10 Thread Matthew Dillon

: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


pkgsrc reports

2011-05-10 Thread Justin Sherrill
I have two reports on recent pkgsrc builds, so I'll just send the URLs
instead of forwarding each:

DragonFly 2.11, x86_64, pkgsrc-2011Q1:

http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110508.2107/meta/report.html

DragonFly 2.10, i386, pkgsrc-2011Q1: (x86_64 report filepath has been
fixed for next build)

http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110510.2020/meta/report.html

security/heimdal is the only real stumbling block right now.


deduping

2011-05-10 Thread Pierre Abbat
I upgraded my Hammer filesystems to version 5 and haven't seen any deduping 
when it runs its nightly cron job. I guess that means I have to run viconfig?

Pierre
-- 
lo ponse be lo mruli po'o cu ga'ezga roda lo ka dinko


Re: deduping

2011-05-10 Thread Max Herrgard

11 maj 2011 kl. 07.44 skrev Max Herrgard:

 11 maj 2011 kl. 06.36 skrev Pierre Abbat:
 I upgraded my Hammer filesystems to version 5 and haven't seen any deduping 
 when it runs its nightly cron job. I guess that means I have to run viconfig?
 
 Hm. I'm not sure I noticed any difference in the nightly cron job's output.
 
 Take a look at the 'dedup' and 'dedup-simulate' targets in hammer(8).

Ah, yeah, hammer viconfig for that.


-max


Re: deduping

2011-05-10 Thread Max Herrgard
11 maj 2011 kl. 07.48 skrev Max Herrgard:
 11 maj 2011 kl. 07.44 skrev Max Herrgard:
 11 maj 2011 kl. 06.36 skrev Pierre Abbat:
 I upgraded my Hammer filesystems to version 5 and haven't seen any deduping 
 when it runs its nightly cron job. I guess that means I have to run 
 viconfig?
 
 Hm. I'm not sure I noticed any difference in the nightly cron job's output.
 
 Take a look at the 'dedup' and 'dedup-simulate' targets in hammer(8).
 
 Ah, yeah, hammer viconfig for that.

Since I haven't had my morning coffee yet, I might as well add that you need to 
run viconfig and add the dedup on every PFS (/home, /usr, etc) you want it to 
run on.

My configs looks like this:
snapshots 1d 60d
prune 1d 5m
rebalance 1d 5m
dedup  1d 5m
reblock   1d 5m
recopy30d 10m


Cheers,
Max