Re: Errors on SSD
On Sun, Aug 26, 2012 at 06:21:46PM +0200, Francois Tigeot wrote: > On Sun, Aug 26, 2012 at 02:47:54PM +0200, Sven Gaerner wrote: > > > > Thanks. Then my assumption was ok. The disk is dying, so I'll have some > > time left to move my data on a magnetic disk and will see how long the > > SSD will work as swapcache. > > > > Do you have a recommendation for SSDs? > > Intel and Crucial models are fine; some dragonflybsd.org servers use > Crucial M4 SSDs for swapcache. > > Some other brands may be ok too; having a look at reviews on e.g. newegg.com > should give you a good idea wrt current models. > > This web page has some return rate statistics: > http://www.behardware.com/articles/862-7/components-returns-rates-6.html > (OCZ numbers are exceptional *ahem*) > > -- > Francois Tigeot Thanks for the links and hints. The next SSD will hopefully work for a longer time. Sven
Re: Errors on SSD
On Sun, Aug 26, 2012 at 08:12:58AM +0200, Francois Tigeot wrote: > Hi, > > On Sat, Aug 25, 2012 at 11:03:42AM +0200, Sven Gaerner wrote: > > > > ahci0.2: Found DISK "OCZ-VERTEX2 1.29" serial="OCZ-CU25VMZ6117F3NFM" > > These messages report disk errors, your drive is dead or dying. > > OCZ has probably the worst failure rate of all SSD brands; I'll avoid > their products like the plague. > > -- > Francois Tigeot Thanks. Then my assumption was ok. The disk is dying, so I'll have some time left to move my data on a magnetic disk and will see how long the SSD will work as swapcache. Do you have a recommendation for SSDs? Sven
Errors on SSD
Hi, I updated my system to the latest release version. The uname says: 3.0-RELEASE DragonFly v3.0.3.1.g2c987-RELEASE. I guess it is not related to the kernel version, but I'm getting these messages on the console. I didn't see them before. ahci0.2: TFES slot 21 ci_saved = 0020 ahci0.2: disk_rw: error ahci0.2: TFES slot 22 ci_saved = 0040 ahci0.2: disk_rw: error ahci0.2: TFES slot 22 ci_saved = 0040 ahci0.2: disk_rw: error ahci0.2: TFES slot 3 ci_saved = 0008 ahci0.2: disk_rw: error ahci0.2: TFES slot 5 ci_saved = 0020 ahci0.2: disk_rw: error ahci0.2: TFES slot 7 ci_saved = 0080 ahci0.2: disk_rw: error That device is an SSD. ahci0.2: Caps 42006 ahci0.2: PMPROBE(2) No Port Multiplier was found. ahci0.2: PMPROBE(2) No Port Multiplier was found. ahci0.2: Found DISK "OCZ-VERTEX2 1.29" serial="OCZ-CU25VMZ6117F3NFM" ahci0.2: tags=32/32 satacap=0706 satafea=004c NCQ=YES capacity=57241.89MB ahci0.2: f85=7069 f86=b401 f87=6163 WC=enabled RA=enabled SEC=freezing I'm using that disk for the root file system, including /tmp, /usr, /var and for running swapcache. All other stuff are on magnetic hard disks. The usual hammer configuration has been modified to reduce writing to the disk and follows Matt's suggestions [1]. Thanks to hammer a backup of the PFSs is not a problem. But I would like to know if someone else has seen those messages and can provide some details about possible errors. Do I have to expect a failing disk soon? I also have set kern.cam.da.2.trim_enabled to 1. Thanks. Sven [1] http://leaf.dragonflybsd.org/mailarchive/users/2012-08/msg0.html
Re: frequency scaling on D525MW not working properly
On Fri, Aug 03, 2012 at 09:22:12AM +0800, Sepherosa Ziehau wrote: > On Fri, Aug 3, 2012 at 2:00 AM, Sven Gaerner wrote: > > On Tue, Jul 31, 2012 at 09:27:15AM +0800, Sepherosa Ziehau wrote: > >> On Tue, Jul 31, 2012 at 5:01 AM, Sven Gaerner wrote: > >> [...] > >> > >> Hmm, maybe i8254 is not working at all. Could you post following > >> information: > >> - bootverbose dmesg w/ hw.i8254.intr_disable="0" in /boot/loader.conf > >> - sysctl kern.cputimer > >> - sysctl hw.acpi > > > > Attached the requested details. > > Grrr, only C1 is detected. If the CPU does support C3, there could be > some settings in BIOS? > > Best Regards, > sephe > > -- > Tomorrow Will Never Die The BIOS settings are very limited. I did not find anything that looks like configuring the C-states. You can just enable/disable the HPET timer, the ACPI wake states (S1 or S3) and other settings that are not related to ACPI/frequency scaling like configuring the USB ports. It looks like FreeBSD also doesn't detect the settings well: http://lists.freebsd.org/pipermail/freebsd-acpi/2011-August/007264.html I guess there is no chance to get C3 states working. I looked into the manual [1] and on page 28ff the table lists the expected power consumption when the system is in various states. I did not see any C3 state there, only C1. So I guess I have to use this board with the limitation or think about changing to a board that supports frequency scaling. Thanks for your support. Regards, Sven [1] http://downloadmirror.intel.com/19123/eng/D525MW_D525MWV_TechProdSpec.pdf
Re: solid-state drives
On Wed, Aug 01, 2012 at 06:16:13PM -0400, Pierre Abbat wrote: > This is a spinoff of the Aleutia question, since Aleutia puts SSDs in > computers. How does the periodic Hammer job handle SSDs? Does reblocking do > anything different than on an HDD? If a computer has an SSD and an HDD, which > should get the swap space? > > Pierre On my workstation I use an SSD for the root filesystem, swapcache and /usr/pkg. The current configuration has snapshots set to 1d (10d retention time) and reblocking is set to 7d (1m runtime). All other option (prune, rebalance, dedup and recopy) are disabled. Currently it is running fine, but in my opinion running swapcache on a workstation that just runs for a couple of hours is not always necessary. I'm just running this setup to play with the swapcache and the SSD, because I think it is a very nice feature. Regards, Sven
Re: frequency scaling on D525MW not working properly
On Tue, Jul 24, 2012 at 09:59:35AM +0800, Sepherosa Ziehau wrote: > On Tue, Jul 24, 2012 at 9:57 AM, Sepherosa Ziehau wrote: > > On Tue, Jul 24, 2012 at 3:24 AM, Sven Gaerner wrote: > >> On Mon, Jul 23, 2012 at 09:44:06AM +0800, Sepherosa Ziehau wrote: > >>> On Mon, Jul 23, 2012 at 3:27 AM, Sascha Wildner wrote: > >>> > On Sun, 22 Jul 2012 21:16:54 +0200, Sven Gaerner > >>> > wrote: > >>> > > >>> >> On Sun, Jul 22, 2012 at 08:31:41PM +0200, Sascha Wildner wrote: > >>> >>> > >>> >>> On Sun, 22 Jul 2012 13:46:41 +0200, Sven Gaerner > >>> >>> wrote: > >>> >>> > >>> >>> >[...] > >>> > > > > I mean following steps: > > 1) Add the following line into into /boot/loader.conf, then reboot: > > hw.i8254.intr_disable="0" > > 2) sysctl hw.acpi.cpu.cx_lowest=C3 > > I mean do step1) first, then do step 2) after step1)'s reboot. I did that, but I cannot set hw.acpi.cpu.cx_lowest=C3. I always get "Invalid argument" when running "sudo sysctl hw.acpi.cpu.cx_lowest=C3". Regards, Sven
Re: frequency scaling on D525MW not working properly
On Wed, Jul 25, 2012 at 10:02:58AM +0200, Sascha Wildner wrote: > As Brian Mastenbrook pointed out in a comment on the digest, the > Atom should support P4TCC: > > http://www.shiningsilence.com/dbsdlog/2012/07/24/10128.html > > Check your CPU features in dmesg. It should show the TM feature, as > it does on my Atom 330 (second to last): > > Features=0xbfe9fbff > > Compiling the kernel with CPU_ENABLE_TCC gives new dmesg and sysctls: > > almsta# grep TCC /var/run/dmesg.boot > Pentium 4 TCC support enabled, current performance 13% > almsta# sysctl hw.p4tcc > hw.p4tcc.cpuperf: 13 > hw.p4tcc.cpuperf_performance: 100 > hw.p4tcc.cpuperf_economy: 13 > > However, a quick test with factor(6) showed no difference between 13 > and 100: > > almsta# sysctl hw.p4tcc.cpuperf=100 > hw.p4tcc.cpuperf: 13 -> 100 > almsta# time factor 23424111 > 23424111: 7 7 4780430839 > 4.726u 0.000s 0:04.77 98.9% 16+66k 0+0io 0pf+0w > > almsta# sysctl hw.p4tcc.cpuperf=13 > hw.p4tcc.cpuperf: 100 -> 13 > almsta# time factor 23424111 > 23424111: 7 7 4780430839 > 4.726u 0.007s 0:04.77 98.9% 16+66k 0+0io 0pf+0w > > Anyway, if your system is i386, try out adding "options > CPU_ENABLE_TCC" to the config and see what it gives. > > I'll see later today about providing it for x86_64 too. > > Sascha Thanks a lot for all the hints. I will try this options these days and get back with the results. Sven
Re: frequency scaling on D525MW not working properly
On Mon, Jul 23, 2012 at 10:28:14AM +, Adrian Bocaniciu wrote: > > Intel Atom processors, unlike more expensive Intel processors, do not > support frequency scaling. > > See for example the specifications for Atom D525 at: > http://ark.intel.com/products/49490/ > > where it is stated that Enhanced Intel SpeedStep Technology is not > supported. The same is written in all Atom datasheets. > > The only way to reduce the power consumption of Atom is to ensure that > the processor is halted when it has nothing to do, i.e. in the idle > loop, which I suppose that DragonFlyBSD does, or to use the ACPI C3 > sleep state whenever you can tolerate the latency required for waking up > the processor. > > I also have a couple of D525MW boards, but I have not tested > DragonFlyBSD on them, and they are much less warm, but my Mini-ITX cases > (Lian Li & Antec) have case coolers that ensure an adequate air flow > inside the cases even if both the motherboards and the power supplies > are fanless. Thanks for the details. I did not look at that point as I expected at least frequency scaling which is supported by the Atom on the Fit-PC2 I also use. I think I will try to get the temperature down by using a fan. But then it is no longer a fanless system that I wanted to have running all the time. And a system in a mini-ITX case with a temperature of 55 degrees is not what I want to have running all the time. Thanks all for the help. I guess I will have to think about a replacement to get a cooler fanless system. Regards, Sven
Re: frequency scaling on D525MW not working properly
On Mon, Jul 23, 2012 at 09:44:06AM +0800, Sepherosa Ziehau wrote: > On Mon, Jul 23, 2012 at 3:27 AM, Sascha Wildner wrote: > > On Sun, 22 Jul 2012 21:16:54 +0200, Sven Gaerner wrote: > > > >> On Sun, Jul 22, 2012 at 08:31:41PM +0200, Sascha Wildner wrote: > >>> > >>> On Sun, 22 Jul 2012 13:46:41 +0200, Sven Gaerner > >>> wrote: > >>> > >>> >[...] > > Hmm, disabling UEFI is OK, but make sure that you have enabled EST in > BIOS (something probably read like "enhanced speed step" or something > like "P-state"). There is no such option. And the only UEFI option is to enable booting of an UEFI compliant OS. Speed stepping cannot be configured. The BIOS options are very limited. > Besides CPU P-State, you could also set allowable CPU C-State to C3 by > setting sysctl hw.acpi.cpu.cx_lowest and put tunable > hw.i8254.intr_disable="0" in /boot/loader.conf (you need to reboot > after changing /boot/loader.conf). However, it should be noted that > enabling C3 will disable LAPIC timer and i8254 timer will be used > instead, which may cause extra overhead. This seems not to change anything. The temperature remains the same. And setting hw.acpi.cpu.cx_lowest returns with "Invalid Argument". Updating the BIOS to a more recent version did also not help. Thanks for your hints. Sven
Re: frequency scaling on D525MW not working properly
On Sun, Jul 22, 2012 at 08:31:41PM +0200, Sascha Wildner wrote: > On Sun, 22 Jul 2012 13:46:41 +0200, Sven Gaerner wrote: > > >[...] > >Also there is no sysctl hw.acpi.cpu.px_dom0.select available, > >so I guess powerd is also running not properly and the CPU > >frequency is not > >scaled in any way. After looking into the dmesg output, I guess > >some driver does > >not recognize parts of the hardware/ACPI stuff correctly (see > >below; the text is > >repeated for the other 3 logical CPUs). cpu0: on acpi0 cpu_cst0: > >on cpu0 cpu_pst0: > >Can't get _PSS package - AE_NOT_FOUND The dmesg is attached. It > >would be great > >if there is someone who can help me to get this fixed. If more > >details are > >necessary, just let me know. Sven > > Is this a mobo with UEFI? > > Sascha Yes, but booting via UEFI is disabled. Sven
frequency scaling on D525MW not working properly
Hello, I bought an Atom based Intel D525MW board. DragonFly release is running on that system. But I have a few minor issues. The CPU is getting somewhat warm (about 55 degrees celsius). This is not a real problem, because it is not too hot. But I think this occurs because the frequency scaling does not work. Running "sysctl hw.acpi" prints the following lines (I cut the output to one logical CPU, but for the other three the output is identical): hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu0.cx_supported: C1/3 hw.acpi.cpu0.cx_lowest: C1 hw.acpi.cpu0.cx_usage: 100.00% last 5000us Also there is no sysctl hw.acpi.cpu.px_dom0.select available, so I guess powerd is also running not properly and the CPU frequency is not scaled in any way. After looking into the dmesg output, I guess some driver does not recognize parts of the hardware/ACPI stuff correctly (see below; the text is repeated for the other 3 logical CPUs). cpu0: on acpi0 cpu_cst0: on cpu0 cpu_pst0: Can't get _PSS package - AE_NOT_FOUND The dmesg is attached. It would be great if there is someone who can help me to get this fixed. If more details are necessary, just let me know. Sven Copyright (c) 2003-2012 The DragonFly Project. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. DragonFly v3.0.2.70.gd51ef-RELEASE #2: Thu Jul 19 22:17:26 CEST 2012 r...@marvin.fritz.box:/usr/obj/usr/src/sys/GENERIC TSC clock: 1800110025 Hz, i8254 clock: 1193212 Hz CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106ca Stepping = 10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x2010 AMD Features2=0x1 real memory = 4277054464 (4078 MB) avail memory = 3344994304 (3190 MB) lapic: divisor index 0, frequency 13876 Hz Initialize MI interrupts module_register: module dsched_fq already exists! Module dsched_fq failed to register: 17 module_register_init: MOD_LOAD (powernow, c0ddadba, 0) error 2 FQ scheduler policy version 1.1 loaded FQ scheduler policy unloaded module_register_init: MOD_LOAD (dsched_fq, c0dde030, 0) error 17 kbd0 at kbdmux0 disk scheduler: set policy of md0 to noop md0: Malloc disk ACPI: RSDP 0xf2060 00024 (v2 INTEL ) ACPI: XSDT 0xceffe120 0004C (v1 INTEL D525MW 0053 0113) ACPI: FACP 0xceffd000 000F4 (v3 INTEL D525MW 0053 MSFT 010D) ACPI: DSDT 0xceff9000 03796 (v1 INTEL D525MW 0053 MSFT 010D) ACPI: FACS 0xcef87000 00040 ACPI: APIC 0xceff8000 00084 (v2 INTEL D525MW 0053 MSFT 010D) ACPI: MCFG 0xceff7000 0003C (v1 INTEL D525MW 0053 MSFT 010D) ACPI: HPET 0xceff6000 00038 (v1 INTEL D525MW 0053 MSFT 010D) ACPI: SSDT 0xceff2000 0377C (v1 INTEL D525MW 0053 MSFT 010D) npx0: on motherboard npx0: INT 16 interface Using XMM optimized bcopy/copyin/copyout cryptosoft0: on motherboard acpi0: on motherboard ACPI FADT: SCI testing interrupt mode ... sched_ithd: stray interrupt 9 on cpu0 ACPI FADT: SCI select level/high objcache_reclaimlist objcache_reclaimlist objcache_reclaimlist objcache_reclaimlist acpi0: Power Button (fixed) Warning: ACPI is disabling APM's device. You can't run both acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 acpi_hpet0: frequency 14318180 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20c0-0x20c7 mem 0xf010-0xf01f,0xe000-0xefff,0xf020-0xf027 irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 8188k stolen memory agp0: aperture size is 256M pci0: (vendor 0x8086, dev 0x27d8) at device 27.0 irq 22 pcib1: at device 28.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0xf000-0xf0003fff,0xf0004000-0xf0004fff irq 16 at device 0.0 on pci1 re0: Hardware rev. 0x2c00; MAC ver. 0x2f; PCI-E 125MHz miibus0: on re0 rgephy0: <8211B/RTL8169S/8110S media interface> on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: MAC address: e8:40:f2:3d:9b:10 pcib2: at device 28.1 on pci0 pci2: on pcib2 pcib3: at device 28.2 on pci0 pci3: on pcib3 pcib4: at device 28.3 on pci0 pci4: on pcib4 uhci0: port 0x2080-0x209f irq 23 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2060-0x207f irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2040-0x205f irq 18 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2020-0x203f irq 16 at device 29.3 on pci0 usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf
Re: recovering a file: hammer history != undo -ai
On Wed, Jun 13, 2012 at 09:55:06PM -0300, Raimundo Santos wrote: > Many thanks, Sven! > > One question: it will replicate the data, creating new nodes in the btree, > or just recover de file with their btree nodes? It will create a new node. It is just a normal file copy, nothing special except looking up the source file. But that is HAMMER's part. I'm not sure but I would guess you can avoid this by enabling dedup on that filesystem. Sven
Re: recovering a file: hammer history != undo -ai
On Wed, Jun 13, 2012 at 01:45:33AM -0300, Raimundo Santos wrote: > Hello, > > I am trying to recover a test image (10GB) which I have deleted. The file > is present in various of my snapshots, and I do not realize how to recover > it: > > . by cpdup from a snapshot to their directory? > . by simply cp from a snapshot to their directory? > . by undo -o test.img test.img@@0xlast_tid? $ cp /path/to/image/test.img@@0xlast_tid test.img or $ cp /var/hammer///test.img test.img should restore the image. Sven
Re: Recover slave PFS
Antonio, > You can use hammer info to display all the existing PFSs among other things. > It will tell you also if they are mounted or not. Thanks for the hint. I saw the output of "hammer info" but I'm confused because for my external hard disk 5 slaves are shown, but only two are configured and useable. > Cheers, > Antonio Huete Regards, Sven
Re: Recover slave PFS
On Sat, Aug 06, 2011 at 04:43:43PM -0700, Matthew Dillon wrote: > It is a bug, it shouldn't have removed the softlink for the PFS. > However, the > only way to destroy a pfs is with pfs-destroy and since you didn't do > that the > PFS is still intact. Thanks for pointing this out. I guessed that because the space was still allocated. > All you have to do is re-create the softlink. > > The PFS softlink points to "@@-1:n" Where 'n' is the pfs number. For > example, > PFS #5 would be: "@@-1:5" > > The format must be precise. If you recreate the softlink for the missing > pfs in > your /pfs directory you should be able to CD into it and get it back. > > If you don't know the PFS number look at the PFS numbers for the existing > PFS's and > guess at the ones that might be missing. > > -Matt It worked by re-creating the softlink. Very nice. It was the first PSF on that device, so I did not have to test a lot. Is there a way to list all allocated but not referenced PSF? Thanks a lot. Sven
Re: Recover slave PFS
Hi, > For testing purposes I created a slave PFS and then issue the above > mentioned call again. Also if using an invalid transcation ID the PFS > is removed. Some notes after looking at the code sbin/hammer/cmd_snapshot.c regarding the above issue. >From the man page the calls are: hammer snaprm ... hammer snaprm ... hammer snaprm ... The first one looks good, just remove a snapshot link (softlink to transaction ID). The second one also looks good, just remove a snapshot by it's transaction ID for the current PSF. But the third one will remove anything that is a link. So running the following command, will remove the PFS /pfs/test. hammer snaprm /pfs/test 0x040 If I understand the code correctly, then /pfs/test is always removed, also if the transcation ID is invalid. I'm not quite sure if my understanding is right, but if I think this is a bug. Before calling remove() to remove the link it should be checked if the link is a softlink to a transcation ID, and only then it should be removed. Or did I miss something? Thanks a lot. Regards, Sven
Recover slave PFS
Hi, I use an external hard disk as simple backup solution to mirror-copy some PFS. Unfortunately I made a mistake when playing with snapshots and "hammer snaprm". I should have read the manual page better. ;) I run $ hammer snaprm /mnt/pfs/slave-pfs 0x0001123 where 0x0001123 was a valid transcation ID, listed by "hammer snapls". After that call the slave PFS is gone. When running df it seems that the space is still allocated. I wonder if it is possible to recover the PFS without running mirror-copy to copy all the stuff again? If not, how do I reclaim the used space? Can I run "hammer recover" on that mounted device to get a valid pointer to a transaction ID? I also tried "hammer history" to find a revision that include the PFS, but wihtout luck. For testing purposes I created a slave PFS and then issue the above mentioned call again. Also if using an invalid transcation ID the PFS is removed. I'm running the 2.10 release version updated to latest 2.10 HEAD. Thanks a lot. Regards, Sven
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 '. > 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: AHCI Problems using master (a80975a)
On Wed, 13 Apr 2011 08:29:39 +0800 Sepherosa Ziehau wrote: > On Wed, Apr 13, 2011 at 5:04 AM, Sven Gaerner > wrote: > > Hi, > > > > I just upgraded to master (a8097a) from the latest 2_8 branch > > commit and rebuild and installed world and kernel. After booting > > the upgraded system xpt fails to configure and mounting the root > > filesystem also fails. > > > > The reported error is: > > hammer_mountroot: can't find devvp > > > > After booting with AHCI disabled, the system starts up, still > > reporting xpt errors, but mounting the root filesystem succeeded. > > So I can use the system. > > > > My /boot/loader.conf: > > > > vfs.root.mountfrom="hammer:serno/WD-WXC0A9997024.s2d" > > kern.emergency_intr_enable=1 > > if_ath_load="YES" > > snd_hda_load="YES" > > dm_load="YES" > > loader_color="YES" > > > > I guess the xpt problem is not the reason why root cannot be > > mounted, because the errors are also shown if AHCI is disabled. > > The problem with the root filesystem seems to be that the hard > > drives are not detected properly. The prompt that is shown if > > booting with AHCI enabled fails also does not show the hard drives. > > > > I attached a dmesg created after > > set hint.ahci.disabled=1 > > boot -v > > > > Are there any hints how to get more details on that problem or how > > to solve it? > > I suggest you to build X86_64_GENERIC_SMP instead of X86_64_GENERIC > > Best Regards, > sephe > > Best Regards, > sephe > Thanks for the suggestion. This works indeed, but with that kernel version, my USB keyboard was not usable. But after upgrading to a more recent master version, everything works fine now. Regards, Sven -- Key ID: 0xD68663A2http://wwwkeys.de.pgp.net/ Visit http://www.gnupg.org/ to get usage information.
AHCI Problems using master (a80975a)
Hi, I just upgraded to master (a8097a) from the latest 2_8 branch commit and rebuild and installed world and kernel. After booting the upgraded system xpt fails to configure and mounting the root filesystem also fails. The reported error is: hammer_mountroot: can't find devvp After booting with AHCI disabled, the system starts up, still reporting xpt errors, but mounting the root filesystem succeeded. So I can use the system. My /boot/loader.conf: vfs.root.mountfrom="hammer:serno/WD-WXC0A9997024.s2d" kern.emergency_intr_enable=1 if_ath_load="YES" snd_hda_load="YES" dm_load="YES" loader_color="YES" I guess the xpt problem is not the reason why root cannot be mounted, because the errors are also shown if AHCI is disabled. The problem with the root filesystem seems to be that the hard drives are not detected properly. The prompt that is shown if booting with AHCI enabled fails also does not show the hard drives. I attached a dmesg created after set hint.ahci.disabled=1 boot -v Are there any hints how to get more details on that problem or how to solve it? Thanks a lot. Sven dmesg_2_9_noahci_verbose Description: Binary data
