Re: Problems adding Intel 750 to zfs pool
This will almost certainly be due to slow TRIM support on the device. Try setting the sysctl vfs.zfs.vdev.trim_on_init to 0 before adding the devices. On 18/07/2015 05:35, dy...@techtangents.com wrote: Hi, I've installed an Intel 750 400GB NVMe PCIe SSD in a Dell R320 running FreeBSD 10.2-beta-1... not STABLE, but not far behind, I think. Apologies if this is the wrong mailing list, or if this has been fixed in STABLE since the beta. Anyway, I've gparted it into 2 partitions - 16GB for slog/zil and 357GB for l2arc. Adding the slog partition to the pool takes about 2 minutes - machine seems hung during that time. Ping works, but I can't open another ssh session. Adding the l2arc doesn't seem to complete - it's been going 10 minutes now and nothing. Ping works, but I can't log in to the local console or another ssh session. I'm adding the partitions using their gpt names. i.e. zpool add zroot log gpt/slog zpool add zroot cache gpt/l2arc The system BIOS is up-to-date. The OS was a fresh 10.1 install, then freebsd-update to 10.2-beta2. 10.1 exhibited the same symptoms. Root is on zfs. Device was tested to be working on Windows 8.1 on a Dell T1700 workstation. Any ideas? Cheers, Dylan Just ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems adding Intel 750 to zfs pool
I wonder if this is connected to NVMe? Our SATA Intel DC S3500 drives (which are not that different to the 750s) TRIM much more quickly. What does camcontrol think the secure erase time should be? For a 600GB S3500 camcontrol accurately gives the secure erase time as 4 minutes: # camcontrol security ada0 erase time4 min enhanced erase time 4 min Trimming drives before addition to a system is definitely worthwhile. Will > On 20 Jul 2015, at 10:28, Steven Hartland wrote: > > This will almost certainly be due to slow TRIM support on the device. > > Try setting the sysctl vfs.zfs.vdev.trim_on_init to 0 before adding the > devices. > > On 18/07/2015 05:35, dy...@techtangents.com wrote: >> Hi, >> >> I've installed an Intel 750 400GB NVMe PCIe SSD in a Dell R320 running >> FreeBSD 10.2-beta-1... not STABLE, but not far behind, I think. Apologies if >> this is the wrong mailing list, or if this has been fixed in STABLE since >> the beta. >> >> Anyway, I've gparted it into 2 partitions - 16GB for slog/zil and 357GB for >> l2arc. Adding the slog partition to the pool takes about 2 minutes - machine >> seems hung during that time. Ping works, but I can't open another ssh >> session. >> >> Adding the l2arc doesn't seem to complete - it's been going 10 minutes now >> and nothing. Ping works, but I can't log in to the local console or another >> ssh session. >> >> I'm adding the partitions using their gpt names. i.e. >> zpool add zroot log gpt/slog >> zpool add zroot cache gpt/l2arc >> >> The system BIOS is up-to-date. The OS was a fresh 10.1 install, then >> freebsd-update to 10.2-beta2. 10.1 exhibited the same symptoms. >> >> Root is on zfs. >> >> Device was tested to be working on Windows 8.1 on a Dell T1700 workstation. >> >> Any ideas? >> >> Cheers, >> >> Dylan Just >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: cannot compile net/mosquitto port 10.1-STABLE
Am 2015-07-20 7:25, schrieb Olli Hauer: > Hi Beat, > > it is possible mosquitto builds against an older lib or header that is not up > to date. > > Can you run the following command.to [1] create a backup > $ cd empyy_space > $ pkg create mosquitto > > Now remove the old.mosquotto package if you have a baxkup.and try to > build.the new version. Ok, found it (partially) rebuilt libxslt cmake and python27 did not solve the problem. The old mosquitto version itself seeed to be the problem. then: make deinstall / make install was a success. normally i use portmaster, or years ago portupgrade for this tasks and it is very rarely that this is not working... regards, Beat Links: -- [1] http://command.to ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems adding Intel 750 to zfs pool
Those figures are often inaccurate as the actual results can vary wildly based of if the device FW thinks there is actual data on the sectors being TRIM'ed. Regards Steve On 20/07/2015 12:06, Will Green wrote: I wonder if this is connected to NVMe? Our SATA Intel DC S3500 drives (which are not that different to the 750s) TRIM much more quickly. What does camcontrol think the secure erase time should be? For a 600GB S3500 camcontrol accurately gives the secure erase time as 4 minutes: # camcontrol security ada0 erase time4 min enhanced erase time 4 min Trimming drives before addition to a system is definitely worthwhile. Will On 20 Jul 2015, at 10:28, Steven Hartland wrote: This will almost certainly be due to slow TRIM support on the device. Try setting the sysctl vfs.zfs.vdev.trim_on_init to 0 before adding the devices. On 18/07/2015 05:35, dy...@techtangents.com wrote: Hi, I've installed an Intel 750 400GB NVMe PCIe SSD in a Dell R320 running FreeBSD 10.2-beta-1... not STABLE, but not far behind, I think. Apologies if this is the wrong mailing list, or if this has been fixed in STABLE since the beta. Anyway, I've gparted it into 2 partitions - 16GB for slog/zil and 357GB for l2arc. Adding the slog partition to the pool takes about 2 minutes - machine seems hung during that time. Ping works, but I can't open another ssh session. Adding the l2arc doesn't seem to complete - it's been going 10 minutes now and nothing. Ping works, but I can't log in to the local console or another ssh session. I'm adding the partitions using their gpt names. i.e. zpool add zroot log gpt/slog zpool add zroot cache gpt/l2arc The system BIOS is up-to-date. The OS was a fresh 10.1 install, then freebsd-update to 10.2-beta2. 10.1 exhibited the same symptoms. Root is on zfs. Device was tested to be working on Windows 8.1 on a Dell T1700 workstation. Any ideas? Cheers, Dylan Just ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with geli and LSI controller
On 20/07/2015 5:56 PM, Marc UBM Bocklet wrote: > On Sun, 19 Jul 2015 09:16:51 -0700 > John-Mark Gurney wrote: > >> Marc UBM via freebsd-stable wrote this message on Sun, Jul 19, 2015 at 17:34 >> +0200: >>> a few weeks ago our Highpoint Rocket Raid controller (hptrr) started >>> biting the dust (spurious channel resets). We bought a LSI 9201-16i >>> (mps) to replace it. Connected to the hptrr were 4 external e-sata >>> enclosures, configured in JBOD mode. Together with two disks connected >>> to the onboard SATA controller, this formed a geli encrypted raidz-2 >>> zpool. >>> Just now, I connected the disks to the mps controller. They show >>> up fine in dmesg. The problem is, when trying to attach the disks >>> formerly connected to the hptrr controller, geli is unable to find the >>> metadata on the disks and errors out with: >>> >>> "geli: Cannot read metadata from /dev/da4: Invalid argument" >>> >>> gpart show says "gpart: No such geom: da4" >>> >>> Trying to restore the geli metadata gives: >>> "geli: Provider size mismatch: wrong backup file?" >>> >>> Is it possible that the hptrr controller handled the disks in some >>> special way and it's only possible to read them there? >> This sounds like the drives were in raid0 mode, and not raw disk >> mode... You might be able to recover the disk w/ geli resize, >> assuming only space was added at the end, not at the begining, but >> I have never personally tried that myself... I'd recommend trying >> on a copy of the drive so you don't loose data if that is possible.. >> >> You can also try to find the old geli label w/ a command like: >> dd if= bs=1m iseek= count=5 | strings -n 9 -td >> >> And get current disk size using diskinfo... >> >> Something like: >> #diskinfo /dev/ada0 >> /dev/ada0 512 3000592982016 5860533168 40960 >> 5814021 16 63 >> #dd if=/dev/ada0 iseek=$((3000592982016/1024/1024-1)) bs=1m 2>/dev/null | >> strings -n 6 -td | grep GEOM:: >> 1530880 GEOM::ELI >> 1531392 GEOM::LABEL >> >> You might have to go farther back than 1 MB... >> >> Good luck... > No luck so far, diskinfo gives me: > > #diskinfo da4 > da4 512 2000398934016 3907029168 40960 243201 255 > 63 > > but > #dd if=/dev/da4 iseek=$((2000398934016/1024/1024-1)) bs=1m 2>/dev/null | > strings -n 6 -td | grep GEOM:: > yields nothing. Marc, Sometimes shell scripts calculations can be daunting. Refer to this $((2000398934016/1024/1024-1)) Now the following portion which converts bytes to MB 2000398934016/1024/1024 that is, dividing bytes by 1M (first by 1KB=1024 then again, means its effectively 1Meg) and you have then subtracted 1 MB from it. To step further back from the end of the hard-disk, you could, for example go back 2MB $((2000398934016/1024/1024-2)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with geli and LSI controller
Hello, > Replying to myself again, it appears that the safest way is to get a > Rocket Raid controller identical to the one we had, put it in another > system, connect the disks, import the old pool and move the data to the > new pool on the the LSI controller. > > Am I overlooking anything? No, that's the way to do it. There are issues with RAID controllers and the way they store the config data. Some store it in the controller, some in some proprietary way on the disks involved. Most of the time, the config data is non-interchangeable between different manufacturers and sometime even between the same manufacturer and different models. It's a mess. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
swapcontext missing in libc.so.7 - 10.2.-BETA2 amd64
please see bug # 201674 @ bugs.freebsd.org for details Bruce Becker+1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmas...@gts.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: iwn & Intel Centrino Advanced-N 6235 support in 10-stable
On Mon, 15 Jun 2015 23:08:36 +0200, Oliver Pinter wrote: On 6/15/15, Ronald Klop wrote: On Wed, 03 Jun 2015 14:25:23 +0200, Oliver Pinter wrote: On 6/3/15, Ronald Klop wrote: Hello, I see support for the 6235 in iwn(4) is committed in Dec 2013 to CURRENT [1]. I would like to buy one of these for a reasonable price [2]. Will it be easy to use the driver from current in 10-stable? Or is there a reason support for this hardware is not MFC'ed? [1] http://svnweb.freebsd.org/base?view=revision&revision=259116 [2] http://www.routercenter.nl/product/294857/intel-centrino-advanced-n-6235.html A recommendation for a better supported card is also welcome. Hi Ronald! Try this branch: https://github.com/opntr/opBSD/tree/op/stable/10-stable-hbsd-iwn . I backported most of the net80211 and iwn related changes till 2014. August to 10-STABLE in this branch. Hi, The card is ordered. Will try your branch soon. Is there more in that branch or only WiFi changes? The changes are ontop of HardenedBSD, so there are many of changes. Cheers, Ronald. Oliver, Thanks for your info. In the end I decided to go with 11-CURRENT which is running ok with this wifi network card while I'm typing this. Regards, Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
MFC r282973 (disable libgomp build) and r283060 (disable libgcov build)?
Should r282973 and r283060 be MFCed to FreeBSD 10? On amd64 and i386, which use clang as their base compiler and don't have gcc in base by default, the math/scilab port uses clang for cc and c++ compilation, but finds /usr/include/omp.h (and links to libgomp from lang/gcc). The build succeeds, but I suspect this may not run properly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with geli and LSI controller
Marc UBM Bocklet wrote this message on Mon, Jul 20, 2015 at 15:29 +0200: > On Mon, 20 Jul 2015 14:56:46 +0200 > Marc "UBM" Bocklet wrote: > > > > > > > This sounds like the drives were in raid0 mode, and not raw disk > > > mode... You might be able to recover the disk w/ geli resize, > > > assuming only space was added at the end, not at the begining, but > > > I have never personally tried that myself... I'd recommend trying > > > on a copy of the drive so you don't loose data if that is possible.. > > > > And one more question, directed at the list: even if geli manages to > > move the metadata via resize, the gpart metadata is probably still > > lost? It depends.. did you gpart it first and the geli it? or the other way around? If you gpart'd it first, you should be able to see your partitions, if you can't then getting a replacement controller card makes the most sense, as it's likely that the RAID card meta data is at the begining of the drive... gpart also supports the resize command... > Replying to myself again, it appears that the safest way is to get a > Rocket Raid controller identical to the one we had, put it in another > system, connect the disks, import the old pool and move the data to the > new pool on the the LSI controller. > > Am I overlooking anything? Nope... As someone else said, this is the dangers of RAID cards... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: swapcontext missing in libc.so.7 - 10.2.-BETA2 amd64
On Mon, 20 Jul 2015, hotlips Internet admin wrote: | |please see bug # 201674 @ bugs.freebsd.org for details sorry for false alarm, a previously uncompleted run of subversion was the problem - PR now closed Bruce Becker+1 416 410 0879 GTS Network Administration Toronto, Ont. Email: hostmas...@gts.infra-service.ca ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
