Re: deduping
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
Re: deduping
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
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). Cheers, Max
deduping
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
pkgsrc reports
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.
Re: System on SSD
On Tue, 10 May 2011 21:16:31 +0200 Matthias Rampke wrote: > 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) The life of an SSD is pretty much determined by how often you write to it. I'm doing something similar with a 40GB Silicon Power V20. I have /var, /tmp, /home. /usr/obj and /usr/pkgobj ($WRKOBJDIR) mounted from hammer PFS on RAID1 HDDs (there are a couple of storage PFSs as well) with everything else (system, pkgrsc, distfiles) in an 8GB UFS partition on the SSD (currently using 3.1G - I only have a very few packages on this box though, if I had more I'd want a bigger partition on the SSD - there's plenty of space). The aim being to put the rapidly changing stuff on HDDs and the frequently used slow changing stuff on the SSD (along with swapcache which has a 16GB swap partition to play in). -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/
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 '. 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
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
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