Re: MPS driver: force bus rescan after remove SAS cable
hi, Am Mittwoch, den 27.04.2011, 20:23 -0700 schrieb Jeremy Chadwick: I don't mean to sound critical, but why do you guys do this? two answers: 1.) Think of: It could happen, instead of it shouldn't happen :-) 2.) Adding a new JBOD on the fly, without reboot the whole machine, what I've done under Solaris and Linux and that wasn't a big deal. It just works. At the moment, replug the SAS cable let you see not all the same disks, like before. Means, replug several times, you get different disks, but most the last 30~46 are missed. However: SAS is a hot pluggable bus, so it should work, but it doesn't. Maybe a bug in the driver or something else. cu denny signature.asc Description: This is a digitally signed message part
Re: correct way to setup gmirror on 7.4?
On 28.04.11 01:30, Freddie Cash wrote: gmirror doesn't touch the start of the disk, but saves it's metadata in the last sector of the disk, and creates a new GEOM provider that's one sector shorter. GPT stores it's partition table in the first sector of the disk, and saves a backup copy of it in the last sector of the disk. This looks like layering issue to me. In theory, both gmirror and gpt should work on 'providers'. So if you give an gmirrored provider to gpt it should touch the last sector of the gmirror, but not the last sector of the disk - and not complain. It should not even be able to see the last sector of the real disk. Is this hard to fix? Daniel ___ 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: correct way to setup gmirror on 7.4?
On Thu, Apr 28, 2011 at 4:15 PM, Daniel Kalchev dan...@digsys.bg wrote: On 28.04.11 01:30, Freddie Cash wrote: gmirror doesn't touch the start of the disk, but saves it's metadata in the last sector of the disk, and creates a new GEOM provider that's one sector shorter. GPT stores it's partition table in the first sector of the disk, and saves a backup copy of it in the last sector of the disk. This looks like layering issue to me. In theory, both gmirror and gpt should work on 'providers'. So if you give an gmirrored provider to gpt it should touch the last sector of the gmirror, but not the last sector of the disk - and not complain. It should not even be able to see the last sector of the real disk. Is this hard to fix? I believe it goes like this gmX: | gpt | data | gpt | which in actual disk goes like this: adY: | gpt | data | gpt | gmirror | so geom read gpt in the first sector but doesn't find it in the last sector. ___ 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: way for failover zpool (no HAST needed): hastmon
hi,
ok, here we go: I've installed hastmon and both FreeBSD nodes and one on
Linux Debian as watchdog:
Simple setup:
# cat /etc.local/hastmon.conf
resource sanip {
exec /usr/local/_rbg/bin/san-ip
friends iscsihead-m iscsihead-s nos
on iscsihead-m {
remote tcp4://iscsihead-s
priority 0
}
on iscsihead-s {
remote tcp4://iscsihead-m
priority 1
}
on linux {
remote tcp4://iscsihead-m tcp4://iscsihead-s
}
}
It works only half.
The simple script adds/remove an alias for the em0 and for status it
does a ping -c 1 to the global ip. After tell every host, what is role
is, I get on the primary state unknown, in the secondary state run
and watchdog for the Linux host.
Than I rebooted the primary, the secondary take over and executed the
script. After the primary was reachable again, he doesn't get the
secondary role, but init/unknown.
The same happens, in the opposite:
from Linux:
hastmonctl status
sanip:
role: watchdog
exec: /usr/local/_rbg/bin/san-ip
remote:
tcp4://iscsihead-m (primary/run)
tcp4://iscsihead-s (init/unknown)
state: run
attempts: 0 from 5
complaints: 0 for last 60 sec (threshold 3)
heartbeat: 10 sec
from iscsihead-s:
hastmonctl status
sanip:
role: init
exec: /usr/local/_rbg/bin/san-ip
remote:
tcp4://iscsihead-m
state: unknown
attempts: 0 from 5
complaints: 0 for last 60 sec (threshold 3)
heartbeat: 10 sec
and last from iscsihead-m
hastmonctl status
sanip:
role: primary
exec: /usr/local/_rbg/bin/san-ip
remote:
tcp4://iscsihead-s (disconnected)
state: run
attempts: 0 from 5
complaints: 0 for last 60 sec (threshold 3)
heartbeat: 10 sec
If I take a look into the logfile from the iscsihead-m:
[sanip] (primary) Remote node acts as init for the resource and not as
secondary.
[sanip] (primary) Handshake header from tcp4://iscsihead-s has no
'token' field.
Do I have missed something?
cu denny
signature.asc
Description: This is a digitally signed message part
ZFS vs OSX Time Machine
Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Any help appreciated, thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: correct way to setup gmirror on 7.4?
On Thu, Apr 28, 2011 at 2:20 AM, Edho P Arief edhopr...@gmail.com wrote: On Thu, Apr 28, 2011 at 4:15 PM, Daniel Kalchev dan...@digsys.bg wrote: On 28.04.11 01:30, Freddie Cash wrote: gmirror doesn't touch the start of the disk, but saves it's metadata in the last sector of the disk, and creates a new GEOM provider that's one sector shorter. GPT stores it's partition table in the first sector of the disk, and saves a backup copy of it in the last sector of the disk. This looks like layering issue to me. In theory, both gmirror and gpt should work on 'providers'. So if you give an gmirrored provider to gpt it should touch the last sector of the gmirror, but not the last sector of the disk - and not complain. It should not even be able to see the last sector of the real disk. Is this hard to fix? I believe it goes like this gmX: | gpt | data | gpt | which in actual disk goes like this: adY: | gpt | data | gpt | gmirror | so geom read gpt in the first sector but doesn't find it in the last sector. Correct. The layering is not, in itself, the issue. The issue is that the loader or kernel or whatever reads the first sector of the disk, finds a GPT so it then looks for the backup GPT in the last physical sector of the disk and doesn't find it. At this point, gmirror is not loaded (or not noticed, since there's nothing in the first sector of the disk to show it's a mirror). Once gmirror is loaded, then the GPT stops complaining as the first and last sectors of the gmirrror provider have the GPT tables. My completely WAG to a fix would be for all GEOM classes to store metadata in the last *and* first sector of the provider. Thus, allowing for proper stacking/layering, and proper, orderly tasting of providors: adX: | gmirror | gpt |data | gpt | gmirror | And to get complicated: adX: | glabel | gmirror | gpt | data | gpt | gmirror | glabel | And so on. Then the loader or kernel or whatever just starts at the beginning of the disk and reads metadata as needed. Granted, there may be reasons why it wasn't done like this in the beginning, but my non-GEOM programmer's eyes can't see any. -- Freddie Cash fjwc...@gmail.com ___ 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: correct way to setup gmirror on 7.4?
On Thu, Apr 28, 2011 at 9:40 PM, Freddie Cash fjwc...@gmail.com wrote: Granted, there may be reasons why it wasn't done like this in the beginning, but my non-GEOM programmer's eyes can't see any. I believe one of the reason is it would prevent conversion from non-gmirror disk to gmirror one as explained here http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html ___ 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: ZFS vs OSX Time Machine
Hi, On 4/28/11 4:03 PM, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. Are you using zfs compression? If so, try turning that off. I have a pool with a couple of filesystems with gzip-9 compression enabled. Whenever I write (using zfs receive, it is a backup server) to one of those volumes the whole pool stalls with lots of disk activity. Even creating a snapshot on another filesystem within the same pool lasts a couple of minutes. Does anyone know how to make this perform a little better? It's only writing small amounts (70-100 ops/s, 1 MB/s) on an otherwise idle pool. Still the drive leds blink like crazy. One of my two CPU cores is maxed out, the other is idle. I suppose it won't get any faster (it's CPU bound because of the heavy gzip compression), but why is the pool so slow? Is zfs receive using synchonous writes? Sorry for maybe being offtopic :-) Regards, Thomas ___ 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: correct way to setup gmirror on 7.4?
Correct. The layering is not, in itself, the issue. The issue is that the loader or kernel or whatever reads the first sector of the disk, finds a GPT so it then looks for the backup GPT in the last physical sector of the disk and doesn't find it. At this point, gmirror is not loaded (or not noticed, since there's nothing in the first sector of the disk to show it's a mirror). Once gmirror is loaded, then the GPT stops complaining as the first and last sectors of the gmirrror provider have the GPT tables. Is not the problem here that you are trying to GPT label a gmirrored disc ? If you instead gmirror two GPT partitions then the problem goes away doesnt it ? Thats how I set things up - use parititoning on the ohysical drives, and then put the mirroring into the partitions thus created. Works fine, and doesnt suffer from any of the afforementioned problems. -pete. ___ 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: correct way to setup gmirror on 7.4?
On Thu, Apr 28, 2011 at 11:43 AM, Pete French petefre...@ingresso.co.uk wrote: Correct. The layering is not, in itself, the issue. The issue is that the loader or kernel or whatever reads the first sector of the disk, finds a GPT so it then looks for the backup GPT in the last physical sector of the disk and doesn't find it. At this point, gmirror is not loaded (or not noticed, since there's nothing in the first sector of the disk to show it's a mirror). Once gmirror is loaded, then the GPT stops complaining as the first and last sectors of the gmirrror provider have the GPT tables. Is not the problem here that you are trying to GPT label a gmirrored disc ? If you instead gmirror two GPT partitions then the problem goes away doesnt it ? Thats how I set things up - use parititoning on the ohysical drives, and then put the mirroring into the partitions thus created. Works fine, and doesnt suffer from any of the afforementioned problems. -pete. ___ 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 Actually I was first creating 2 GPT partitions on each disk and then creating a mirror on each of those partitions (2 partitions per disk, 2 mirrors). When doing that I ran into the secondary GPT block displaying as not found during boot. As I mentioned, I didn't know if that was a problem per-se, which is why I posted to the list to see if there was a better way of mirroring partitions. From what I'm gathering, I think I did things correctly actually. -Proto ___ 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: correct way to setup gmirror on 7.4?
On 28/04/2011 17:02, Edho P Arief wrote: On Thu, Apr 28, 2011 at 9:40 PM, Freddie Cashfjwc...@gmail.com wrote: Granted, there may be reasons why it wasn't done like this in the beginning, but my non-GEOM programmer's eyes can't see any. I believe one of the reason is it would prevent conversion from non-gmirror disk to gmirror one as explained here http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html Actually, storing any kind of metadata in the first sector can lead to weird and unexpected problems with some buggy disk controllers which parse the MBR for some (wrong) reasons. I personally have a disk controller which hangs on boot if the MBR contains anything but primary partitions of DOS type (even changing the partition type makes it hang), and that is not the only disk controller I've seen with this type of a bug. The second reason is that storing anything except the MBR in the first sector makes the drive non-bootable (even if the controller is ok) and it is kind of nice to be able to make a cheap soft-RAID1 from two ordinary (S)ATA drives. ___ 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: correct way to setup gmirror on 7.4?
On Thu, Apr 28, 2011 at 4:43 PM, Pete French petefre...@ingresso.co.uk wrote: Is not the problem here that you are trying to GPT label a gmirrored disc ? If you instead gmirror two GPT partitions then the problem goes away doesnt it ? Thats how I set things up - use parititoning on the ohysical drives, and then put the mirroring into the partitions thus created. Works fine, and doesnt suffer from any of the afforementioned problems. -pete. Is this simple to do? When I setup my home ZFS server, I couldn't get it to boot from ZFS, so I configured 2 disks as 'boot' discs: =34 2930277101 ada5 GPT (1.4T) 34 128 1 (null) (64K) 16212582912 2 root (6.0G) 12583074 2917694061 3 samsung15-1 (1.4T) The other 'boot' disc is configured the same, except it has altroot/samsung15-2 labels on the UFS/ZFS GPT partitions (the other 4 discs have a corresponding 6 GB partition for swap/dumps). However, this is as far as I got. I currently have vfs.root.mountfrom=ufs:/dev/gpt/root, and I'd like to gmirror 'root' onto 'altroot', without overwriting GPT labels or anything dangerous! Cheers Tom ___ 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: correct way to setup gmirror on 7.4?
Is this simple to do? When I setup my home ZFS server, I couldn't get it to boot from ZFS, so I configured 2 disks as 'boot' discs: Its fairly simple - I generally dont boot from ZFs either, my standard config has a 4 gig UFS boot partition, and then a large zpool on the rest of the drive. usually I add in a bit of swap there, which I dnt mirror, so I get swap on each drive. So each disk looks like this with MBR da0s1 - 4 gig for / da0s2 - 2 gig for swap da0s3 - rest of drive for zpool because the gmirror is at the end of the partiton then the boot code finds the UFS filesystem at the start and boots from it not needing to know about gmirror. The gmirror is loaded in the boot process, and then mirrors the drive being booted with the other drive. I can boot of either drive and the system comes up fine. As for the zpool, well that sorts itself out fne, as ZFS is wont to do ;-) =34 2930277101 ada5 GPT (1.4T) 34 128 1 (null) (64K) 16212582912 2 root (6.0G) 12583074 2917694061 3 samsung15-1 (1.4T) The other 'boot' disc is configured the same, except it has altroot/samsung15-2 labels on the UFS/ZFS GPT partitions (the other 4 discs have a corresponding 6 GB partition for swap/dumps). However, this is as far as I got. I currently have vfs.root.mountfrom=ufs:/dev/gpt/root, and I'd like to gmirror 'root' onto 'altroot', without overwriting GPT labels or anything dangerous! I havent tried with GPT, but it should be the same as with MBR. Boot off the 1st drive, create a gmirror inside the root partition on the 2nd drive, newfs it and then cpdup the running system over to it. Make sure you do the necessaries on the 2nd drive to make it bootable as if you just had a standard UFS filesystem in that partition, with no gmirror. Now on te 2nd drive edit loader.conf so it looks something like this: geom_mirror_load=YES vfs.root.mountfrom=ufs:/dev/mirror/mymirror and fstab similarly: /dev/mirror/mymirror / ufs rw 2 2 Yu shuld now be able to boot from the 2nd drive fine. Check that works - it should come up OK, running wth your root on agmirror with a single element on that partition. At this point you can then add in the partition from the first disc to the mirror. Should now boot from either drive fine. as I said, I havent tried it with GPT, but there is no reason I can see that it wudnt work the same as with MBR. The only reason I still stick with MBR is that I like the FreeBSD boot loader which will let me choose F5 to select the next drive to boot from. Last time I looked there wasn't an exquivalent for GPT (if I missed this then I will now feel foolish...) cheers, -pete. ___ 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: ZFS vs OSX Time Machine
I doubt the issues you are encountering have much to do with ZFS. It sounds like you are using TimeMachine over NFS. Obviously, Apple does not support that configuration: http://www.google.com/search?q=time+machine+nfs+site:apple.com In my opinion, TimeMachine should only be used with block storage. If you use any kind of file-sharing protocol (AFP, SMB/CIFS or NFS), TimeMachine is implemented using a sparse disk image broken into hundreds or thousands of separate files. This is a hack at best. Time machine works very well with locally attached storage, but if you need to use network storage, you might want to try iSCSI: http://thegreyblog.blogspot.com/2010/02/using-zfs-with-apple-time-machine.html http://people.freebsd.org/~rse/iscsi/iscsi.txt On Apr 28, 2011, at 7:03 AM, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Any help appreciated, thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: ZFS vs OSX Time Machine
On Thu, Apr 28, 2011 at 10:32 AM, Thomas Ronner tho...@ronner.org wrote: On 4/28/11 4:03 PM, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. Are you using zfs compression? If so, try turning that off. I have a pool with a couple of filesystems with gzip-9 compression enabled. Whenever I write (using zfs receive, it is a backup server) to one of those volumes the whole pool stalls with lots of disk activity. Even creating a snapshot on another filesystem within the same pool lasts a couple of minutes. Does anyone know how to make this perform a little better? It's only writing small amounts (70-100 ops/s, 1 MB/s) on an otherwise idle pool. Still the drive leds blink like crazy. One of my two CPU cores is maxed out, the other is idle. I suppose it won't get any faster (it's CPU bound because of the heavy gzip compression), but why is the pool so slow? Is zfs receive using synchonous writes? gzip-9 is very poor choice for most datasets. It's going to be extremely slow especially with data that can't be compressed easily eg data that already compressed or encrypted. So yeah, if you're running into a cpu bottleneck, change your compression algo. I find lzjb to be a good one for general use. And to the OP, I'm not familar with TM, but see if disabling sendfile in any of your daemons helps. Also I don't think you want this setting: vfs.zfs.cache_flush_disable=1 -- Adam Vande More ___ 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: ZFS vs OSX Time Machine
On Apr 28, 2011, at 7:03 AM, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. Caveat: Time Machine is a viable backup system, but you're outside the configurations which it supports. TM really wants the backup to be located on an HFS+ filesystem because it makes very extensive use of hard links-- including hard links to directories-- which are not widely supported by other Unix filesystems. Even if you choose to continue using ZFS storage, please note that you'll obtain significantly better results by using AFP instead of NFS filesharing. Wikipedia has useful info here: http://en.wikipedia.org/wiki/Time_Machine_%28Mac_OS%29 http://en.wikipedia.org/wiki/Apple_Filing_Protocol Regards, -- -Chuck ___ 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: ZFS vs OSX Time Machine
I am using TM over smb on a ZFS Raidz1 pool of my fileserver with no problems whatsoever. NAME USED AVAIL REFER MOUNTPOINT tank/apple 37.2G 82.8G 37.2G /tank/apple Oldest backup 14 December 2009 On Thu, Apr 28, 2011 at 9:25 PM, Chuck Swiger cswi...@mac.com wrote: On Apr 28, 2011, at 7:03 AM, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. Caveat: Time Machine is a viable backup system, but you're outside the configurations which it supports. TM really wants the backup to be located on an HFS+ filesystem because it makes very extensive use of hard links-- including hard links to directories-- which are not widely supported by other Unix filesystems. Even if you choose to continue using ZFS storage, please note that you'll obtain significantly better results by using AFP instead of NFS filesharing. Wikipedia has useful info here: http://en.wikipedia.org/wiki/Time_Machine_%28Mac_OS%29 http://en.wikipedia.org/wiki/Apple_Filing_Protocol Regards, -- -Chuck ___ 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 -- George Kontostanos aisecure.net http://www.aisecure.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: ZFS vs OSX Time Machine
On Apr 28, 2011, at 12:17 PM, George Kontostanos wrote: I am using TM over smb on a ZFS Raidz1 pool of my fileserver with no problems whatsoever. NAME USED AVAIL REFER MOUNTPOINT tank/apple 37.2G 82.8G 37.2G /tank/apple Oldest backup 14 December 2009 SMB aka CIFS is a better choice than NFS, because it supports better locking (oplocks or stealable locks), but it is not as good as AFP for this particular purpose. Also, ZFS isn't going to be as space efficient at storing TM backups compared with HFS+, because it doesn't support hard links to directories. Regards, -- -Chuck ___ 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: ZFS vs OSX Time Machine
On Thu, Apr 28, 2011 at 11:33:22PM +0930, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. I'm also not sure why you're setting cache_flush_disable at all. Any help appreciated, thanks :) Others seem to be battling stating that NFS doesn't work for TM, but that isn't what you're complaining about. You're complaining that FreeBSD with ZFS + NFS performs extremely poorly when trying to do backups from an OS X client using TM (writing to the NFS mount). I have absolutely no experience with TM or OS X, so if it's actually a client-level problem (which I'm doubting) I can't help you there. Just sort of a ramble here at different things... It would be useful to provide ZFS ARC sysctl data from the FreeBSD system where you're seeing performance issues. sysctl -a kstat.zfs.misc.arcstats should suffice. You should also try executing zpool iostat -v 1 during the TM backup to see if there's a particular device which is behaving poorly. There have been reports of ZFS pools behaving poorly when a single device within the pool has slow I/O (e.g. 5 hard disks, one of which has internal issues, resulting in the entire pool performing horribly). You should let this run for probably 60-120 seconds to get an idea. Given your parameters above (assuming vfs.zfs.txg.timeout IS in fact 5!), you should see bursts of writes every 5 seconds. I know that there are some things on ZFS that perform badly overall. Anything that involves excessive/large numbers of files (not file sizes, but actual files themselves) seems to perform not-so-great with ZFS. For example, Maildir on ZFS = piss-poor performance. There are ways to work around this issue (if I remember correctly, by adding a dedicated log device to your ZFS pool, but be aware your log devices need to be reliable (if you have a single log device and it fails the entire pool is damaged, if I remember right)), but I don't consider it feasible. So if TM is creating tons of files on the NFS mount (backed by ZFS), then I imagine the performance isn't so great. Could you please provide the following sysctl values? Thanks. kern.maxvnodes kern.minvnodes vfs.freevnodes vfs.numvnodes If the FreeBSD machine has a wireless card in it, if at all possible could you try ruling that out by hooking up wired Ethernet instead? It's probably not the cause, but worth trying anyway. If you have a home router or something doing 802.11, don't bother with this idea. Next, you COULD try using Samba/CIFS on the FreeBSD box to see if you can narrow the issue down to bad NFS performance. Please see this post of mine about tuning Samba on FreeBSD (backed by ZFS) to get extremely good performance. Many people responded and said their performance drastically improved (you can see the thread yourself). The trick is AIO. You can ignore the part about setting vm.kmem_size in loader.conf; that advice is now old/deprecated (does not pertain to you given the date of your kernel), and vfs.zfs.txg.write_limit_override is something you shouldn't mess with unless absolutely needed to leave it default: http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061642.html Finally, when was the last time this FreeBSD machine was rebooted? Some people have seen horrible performance that goes away after a reboot. There's some speculation that memory fragmentation has something to do with it. I simply don't know. I'm not telling you to reboot the box (please don't; it would be more useful if it could be kept up in case folks want to do analysis of it). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___
Re: ZFS vs OSX Time Machine
AFP is not the same as HFS+. Time Machine will work better with AFP than NFS or SMB/CIFS, but it's still not using native HFS+ unless you are using block storage (even if you use AFP with an HFS+ filesystem). Time Machine cannot function at all without accessing HFS+ directly. If you are using a network filesystem (AFP, SMB/CIFS or NFS), Time Machine creates a sparse disk image, formatted as HFS+ and stores it on your file-server. It then attaches that disk image as a disk device and mounts it (somewhat like mdconfig -a -t vnode -f /path/to/disk-image -u 1; mount /dev/md1 /mnt). It then treats that disk image basically the same way that it treats local attached storage, including creating hard directory links (but all inside the disk image). See man hdiutil (on OS X) for more info, particularly the part about SPARSEBUNDLEs, sparse images backing HFS+ filesystems and band sizes. Even if you use Mac OS 10 Server and create a Time Machine share (which is the best case scenario), it still uses emulated block storage as described above (disk image over AFP on HFS+). I have personally done this and decided that it was not a very good solution. Your milage may very. I know that people do this, but it seems rather silly. If you have the knowledge to use ZFS, use a zvol via iSCSI. It is much more efficient to use a form of network storage that handles block access natively (like iSCSI) instead of accessing emulated block storage via file-sharing protocols that were not designed for such use. ZFS doesn't care what you use it for. If you are using ZFSv28 (I wouldn't use it for critical data on FreeBSD yet) you can even do dedupe and compression on a native HFS+ Time Machine volume (although you would only see the saved space from the perspective of the zpool and make sure you have lots of RAM). On Apr 28, 2011, at 12:33 PM, Chuck Swiger wrote: On Apr 28, 2011, at 12:17 PM, George Kontostanos wrote: I am using TM over smb on a ZFS Raidz1 pool of my fileserver with no problems whatsoever. NAME USED AVAIL REFER MOUNTPOINT tank/apple 37.2G 82.8G 37.2G /tank/apple Oldest backup 14 December 2009 SMB aka CIFS is a better choice than NFS, because it supports better locking (oplocks or stealable locks), but it is not as good as AFP for this particular purpose. Also, ZFS isn't going to be as space efficient at storing TM backups compared with HFS+, because it doesn't support hard links to directories. Regards, -- -Chuck ___ 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
No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
Hi, I've installed Intel Gigabit CT Desktop Adapter in my FreeBSD 8.2 box and I can't see any incoming traffic on this card. Even ARP resolution doesn't work. Though I see the outgoing traffic on the other end. Relevant info: kadlubek# uname -a FreeBSD kadlubek 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #20: Sat Feb 12 21:22:19 CET 2011 root@kadlubek:/usr/obj/usr/src/sys/KADLUB i386 kadlubek# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f mem 0xfe9e-0xfe9f,0xfe90-0xfe97,0xfe9dc000-0xfe9d irq 24 at device 0.0 on pci2 em0: Using MSIX interrupts with 0 vectors em0: [FILTER] kadlubek# ping 192.168.115.1 PING 192.168.115.1 (192.168.115.1): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down In mean time - tcpdump shows: kadlubek# tcpdump -i em0 22:03:55.962118 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:56.967107 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:57.972094 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 I've checked the firewall rules, but there are none there: kadlubek# pfctl -s rules No ALTQ support in kernel ALTQ related functions disabled pciconf -lv shows the card as: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet kadlubek# sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBPG.NPGS dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x02 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1477444168 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 35 dev.em.0.queue0.txd_tail: 35 dev.em.0.queue0.tx_irq: 0 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 117 dev.em.0.queue0.rxd_tail: 1023 dev.em.0.queue0.rx_irq: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 117 dev.em.0.mac_stats.good_pkts_recvd: 117 dev.em.0.mac_stats.bcast_pkts_recvd: 41 dev.em.0.mac_stats.mcast_pkts_recvd: 42 dev.em.0.mac_stats.rx_frames_64: 71 dev.em.0.mac_stats.rx_frames_65_127: 0 dev.em.0.mac_stats.rx_frames_128_255: 35 dev.em.0.mac_stats.rx_frames_256_511: 11 dev.em.0.mac_stats.rx_frames_512_1023: 0 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 15499 dev.em.0.mac_stats.good_octets_txd: 2240 dev.em.0.mac_stats.total_pkts_txd: 35 dev.em.0.mac_stats.good_pkts_txd: 35 dev.em.0.mac_stats.bcast_pkts_txd: 35 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 35 dev.em.0.mac_stats.tx_frames_65_127: 0 dev.em.0.mac_stats.tx_frames_128_255: 0 dev.em.0.mac_stats.tx_frames_256_511: 0 dev.em.0.mac_stats.tx_frames_512_1023: 0 dev.em.0.mac_stats.tx_frames_1024_1522: 0 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 2 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.0.wake: 0 kadlubek# sysctl dev.em.0.debug=1 Interface is RUNNING and INACTIVE em0: hw tdh = 35, hw tdt = 35 em0: hw rdh = 118, hw rdt = 1023 em0: Tx Queue Status = 1 em0: TX descriptors avail = 989 em0: Tx Descriptors avail failure = 0 em0: RX discarded packets = 0 em0: RX Next to Check = 0 em0: RX Next to Refresh = 0 I've tried booting linux on this box, and card is detected as follows: [ 16.376557] e1000e: Intel(R) PRO/1000 Network Driver - 1.2.20-k2 [
Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
Notice this: em0: Using MSIX interrupts with 0 vectors ZERO vectors are not a good sign :) You need to look at your system, you have MSIX disabled or something? Maybe some message in /var/log/messages?? Jack On Thu, Apr 28, 2011 at 1:20 PM, Wiktor Niesiobedzki b...@vink.pl wrote: Hi, I've installed Intel Gigabit CT Desktop Adapter in my FreeBSD 8.2 box and I can't see any incoming traffic on this card. Even ARP resolution doesn't work. Though I see the outgoing traffic on the other end. Relevant info: kadlubek# uname -a FreeBSD kadlubek 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #20: Sat Feb 12 21:22:19 CET 2011 root@kadlubek:/usr/obj/usr/src/sys/KADLUB i386 kadlubek# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f mem 0xfe9e-0xfe9f,0xfe90-0xfe97,0xfe9dc000-0xfe9d irq 24 at device 0.0 on pci2 em0: Using MSIX interrupts with 0 vectors em0: [FILTER] kadlubek# ping 192.168.115.1 PING 192.168.115.1 (192.168.115.1): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down In mean time - tcpdump shows: kadlubek# tcpdump -i em0 22:03:55.962118 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:56.967107 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:57.972094 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 I've checked the firewall rules, but there are none there: kadlubek# pfctl -s rules No ALTQ support in kernel ALTQ related functions disabled pciconf -lv shows the card as: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet kadlubek# sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.NBPG.NPGS dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x02 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1477444168 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 35 dev.em.0.queue0.txd_tail: 35 dev.em.0.queue0.tx_irq: 0 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 117 dev.em.0.queue0.rxd_tail: 1023 dev.em.0.queue0.rx_irq: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 117 dev.em.0.mac_stats.good_pkts_recvd: 117 dev.em.0.mac_stats.bcast_pkts_recvd: 41 dev.em.0.mac_stats.mcast_pkts_recvd: 42 dev.em.0.mac_stats.rx_frames_64: 71 dev.em.0.mac_stats.rx_frames_65_127: 0 dev.em.0.mac_stats.rx_frames_128_255: 35 dev.em.0.mac_stats.rx_frames_256_511: 11 dev.em.0.mac_stats.rx_frames_512_1023: 0 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 15499 dev.em.0.mac_stats.good_octets_txd: 2240 dev.em.0.mac_stats.total_pkts_txd: 35 dev.em.0.mac_stats.good_pkts_txd: 35 dev.em.0.mac_stats.bcast_pkts_txd: 35 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 35 dev.em.0.mac_stats.tx_frames_65_127: 0 dev.em.0.mac_stats.tx_frames_128_255: 0 dev.em.0.mac_stats.tx_frames_256_511: 0 dev.em.0.mac_stats.tx_frames_512_1023: 0 dev.em.0.mac_stats.tx_frames_1024_1522: 0 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 2 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.0.wake: 0 kadlubek# sysctl dev.em.0.debug=1
[releng_8 tinderbox] failure on arm/arm
TB --- 2011-04-28 20:03:30 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-04-28 20:03:30 - starting RELENG_8 tinderbox run for arm/arm TB --- 2011-04-28 20:03:30 - cleaning the object tree TB --- 2011-04-28 20:03:37 - cvsupping the source tree TB --- 2011-04-28 20:03:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2011-04-28 20:04:20 - building world TB --- 2011-04-28 20:04:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-28 20:04:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-28 20:04:20 - TARGET=arm TB --- 2011-04-28 20:04:20 - TARGET_ARCH=arm TB --- 2011-04-28 20:04:20 - TZ=UTC TB --- 2011-04-28 20:04:20 - __MAKE_CONF=/dev/null TB --- 2011-04-28 20:04:20 - cd /src TB --- 2011-04-28 20:04:20 - /usr/bin/make -B buildworld World build started on Thu Apr 28 20:04:21 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.sbin/uhsoctl/uhsoctl.1 uhsoctl.1.gz === usr.sbin/usbdump (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-28 21:06:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-28 21:06:31 - ERROR: failed to build world TB --- 2011-04-28 21:06:31 - 2417.55 user 410.77 system 3780.77 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full ___ 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: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
Hi, I really don't know (I haven't done that intentionally). There is nothing special in /var/log/messages: kadlubek# grep -i msix /var/log/messages Apr 28 21:37:03 kadlubek kernel: em0: Using MSIX interrupts with 0 vectors Though sysctl suggests, that I haven't disabled MSIX: kadlubek# sysctl -a | grep -i msix hw.pci.enable_msix: 1 I've checked further pciconf output (now with -c option also) and there is: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled So it looks, like the card supports MSI-X and has them enabled. Though my PCI Express bridges report as: pcib2@pci0:0:2:0: class=0x060400 card=0xc3231106 chip=0xa3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib3@pci0:0:3:0: class=0x060400 card=0xc3231106 chip=0xc3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib5@pci0:128:0:0: class=0x060400 card=0x chip=0x287c1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x2) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib6@pci0:128:0:1: class=0x060400 card=0x0004 chip=0x287d1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x0004 Though they mention that HT MSI windows is disabled. I'm not sure, whether this matters. Cheers, Wiktor 2011/4/28 Jack Vogel jfvo...@gmail.com: Notice this: em0: Using MSIX interrupts with 0 vectors ZERO vectors are not a good sign :) You need to look at your system, you have MSIX disabled or something? Maybe some message in /var/log/messages?? Jack On Thu, Apr 28, 2011 at 1:20 PM, Wiktor Niesiobedzki b...@vink.pl wrote: Hi, I've installed Intel Gigabit CT Desktop Adapter in my FreeBSD 8.2 box and I can't see any incoming traffic on this card. Even ARP resolution doesn't work. Though I see the outgoing traffic on the other end. Relevant info: kadlubek# uname -a FreeBSD kadlubek 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #20: Sat Feb 12 21:22:19 CET 2011 root@kadlubek:/usr/obj/usr/src/sys/KADLUB i386 kadlubek# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f mem 0xfe9e-0xfe9f,0xfe90-0xfe97,0xfe9dc000-0xfe9d irq 24 at device 0.0 on pci2 em0: Using MSIX interrupts with 0 vectors em0: [FILTER] kadlubek# ping 192.168.115.1 PING 192.168.115.1 (192.168.115.1): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down In mean time - tcpdump shows: kadlubek# tcpdump -i em0 22:03:55.962118 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:56.967107 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 22:03:57.972094 ARP, Request who-has 192.168.115.1 tell 192.168.115.220, length 28 I've
Re: ZFS vs OSX Time Machine
On Apr 28, 2011, at 3:56 PM, Jeremy Chadwick wrote: On Thu, Apr 28, 2011 at 11:33:22PM +0930, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. In my /boot/loader.conf I have: vfs.zfs.arc_max=62 vfs.zfs.vdev.min_pending=4 vfs.zfs.vdev.max_pending=8 vfs.zfs.txg.timeout=5 vfs.zfs.prefetch_disable=1 And they all are properly reflected in sysctl values (no parse errors seen). Next, you COULD try using Samba/CIFS on the FreeBSD box to see if you can narrow the issue down to bad NFS performance. Please see this post of mine about tuning Samba on FreeBSD (backed by ZFS) to get extremely good performance. Many people responded and said their performance drastically improved (you can see the thread yourself). The trick is AIO. You can ignore the part about setting vm.kmem_size in loader.conf; that advice is now old/deprecated (does not pertain to you given the date of your kernel), and vfs.zfs.txg.write_limit_override is something you shouldn't mess with unless absolutely needed to leave it default: http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061642.html Just wanted to note that we were having a terrible time with ZFS performance. Copying just a single large file over the network would bring interactive system usage to an absolute crawl (system is 2x xeons, 12gb ram). Thanks to your optimizations we have great ZFS + Samba performance. We also use Netatalk for afpd file sharing (though I have not tried Netatalk as a Time Machine target) and our performance is quite good there as well. Scott ___ 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: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
Well, rebuild your kernel so the driver is not static, then you can load and unload the driver to see what happens. You only have one interface, no em1? Jack On Thu, Apr 28, 2011 at 2:17 PM, Wiktor Niesiobedzki b...@vink.pl wrote: Hi, I really don't know (I haven't done that intentionally). There is nothing special in /var/log/messages: kadlubek# grep -i msix /var/log/messages Apr 28 21:37:03 kadlubek kernel: em0: Using MSIX interrupts with 0 vectors Though sysctl suggests, that I haven't disabled MSIX: kadlubek# sysctl -a | grep -i msix hw.pci.enable_msix: 1 I've checked further pciconf output (now with -c option also) and there is: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled So it looks, like the card supports MSI-X and has them enabled. Though my PCI Express bridges report as: pcib2@pci0:0:2:0: class=0x060400 card=0xc3231106 chip=0xa3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib3@pci0:0:3:0: class=0x060400 card=0xc3231106 chip=0xc3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib5@pci0:128:0:0: class=0x060400 card=0x chip=0x287c1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x2) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib6@pci0:128:0:1: class=0x060400 card=0x0004 chip=0x287d1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x0004 Though they mention that HT MSI windows is disabled. I'm not sure, whether this matters. Cheers, Wiktor 2011/4/28 Jack Vogel jfvo...@gmail.com: Notice this: em0: Using MSIX interrupts with 0 vectors ZERO vectors are not a good sign :) You need to look at your system, you have MSIX disabled or something? Maybe some message in /var/log/messages?? Jack On Thu, Apr 28, 2011 at 1:20 PM, Wiktor Niesiobedzki b...@vink.pl wrote: Hi, I've installed Intel Gigabit CT Desktop Adapter in my FreeBSD 8.2 box and I can't see any incoming traffic on this card. Even ARP resolution doesn't work. Though I see the outgoing traffic on the other end. Relevant info: kadlubek# uname -a FreeBSD kadlubek 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #20: Sat Feb 12 21:22:19 CET 2011 root@kadlubek:/usr/obj/usr/src/sys/KADLUB i386 kadlubek# dmesg | grep em0 em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f mem 0xfe9e-0xfe9f,0xfe90-0xfe97,0xfe9dc000-0xfe9d irq 24 at device 0.0 on pci2 em0: Using MSIX interrupts with 0 vectors em0: [FILTER] kadlubek# ping 192.168.115.1 PING 192.168.115.1 (192.168.115.1): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down In mean time
Re: ZFS vs OSX Time Machine
On Thursday, April 28, 2011 3:56:01 pm Jeremy Chadwick wrote: On Thu, Apr 28, 2011 at 11:33:22PM +0930, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2- PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. Huh? I use values without quotes all the time in loader.conf. -- John Baldwin ___ 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: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: Hi, I really don't know (I haven't done that intentionally). There is nothing special in /var/log/messages: kadlubek# grep -i msix /var/log/messages Apr 28 21:37:03 kadlubek kernel: em0: Using MSIX interrupts with 0 vectors Though sysctl suggests, that I haven't disabled MSIX: kadlubek# sysctl -a | grep -i msix hw.pci.enable_msix: 1 I've checked further pciconf output (now with -c option also) and there is: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled So it looks, like the card supports MSI-X and has them enabled. Though my PCI Express bridges report as: pcib2@pci0:0:2:0: class=0x060400 card=0xc3231106 chip=0xa3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib3@pci0:0:3:0: class=0x060400 card=0xc3231106 chip=0xc3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib5@pci0:128:0:0: class=0x060400 card=0x chip=0x287c1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x2) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib6@pci0:128:0:1: class=0x060400 card=0x0004 chip=0x287d1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x0004 Though they mention that HT MSI windows is disabled. I'm not sure, whether this matters. Yes, that is probably what breaks this. -- John Baldwin ___ 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: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
On Thu, Apr 28, 2011 at 2:28 PM, John Baldwin j...@freebsd.org wrote: On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: Hi, I really don't know (I haven't done that intentionally). There is nothing special in /var/log/messages: kadlubek# grep -i msix /var/log/messages Apr 28 21:37:03 kadlubek kernel: em0: Using MSIX interrupts with 0 vectors Though sysctl suggests, that I haven't disabled MSIX: kadlubek# sysctl -a | grep -i msix hw.pci.enable_msix: 1 I've checked further pciconf output (now with -c option also) and there is: em0@pci0:2:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled So it looks, like the card supports MSI-X and has them enabled. Though my PCI Express bridges report as: pcib2@pci0:0:2:0: class=0x060400 card=0xc3231106 chip=0xa3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib3@pci0:0:3:0: class=0x060400 card=0xc3231106 chip=0xc3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x1(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[98] = PCI Bridge card=0xc3231106 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib5@pci0:128:0:0: class=0x060400 card=0x chip=0x287c1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x2) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0002[140] = VC 1 max VC1 ecap 0005[180] = unknown 1 pcib6@pci0:128:0:1: class=0x060400 card=0x0004 chip=0x287d1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies, Inc.' device = 'VT8251 Standard PCIe Root Port' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(256) link x0(x1) cap 01[68] = powerspec 2 supports D0 D3 current D0 cap 05[70] = MSI supports 1 message, 64 bit, vector masks cap 08[88] = HT MSI fixed address window disabled at 0xfee0 cap 0d[90] = PCI Bridge card=0x0004 Though they mention that HT MSI windows is disabled. I'm not sure, whether this matters. Yes, that is probably what breaks this. -- John Baldwin Opps, missed that, thanks John. So, disable MSIX and MSI using sysctl, then the driver should use legacy when it loads. Still, I'd get a different motherboard, sucks to not have MSIX :( Jack ___ 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: ZFS vs OSX Time Machine
On Thu, Apr 28, 2011 at 05:27:04PM -0400, John Baldwin wrote: On Thursday, April 28, 2011 3:56:01 pm Jeremy Chadwick wrote: On Thu, Apr 28, 2011 at 11:33:22PM +0930, Daniel O'Connor wrote: Does anyone else use ZFS to store TM backups? I find that whenever my laptop (over wifi!) starts a TM the ZFS machine it's backing up to grinds to a halt.. Other systems streaming stuff over NFS from it also tend to stall.. I presume that TM is doing something which causes ZFS some issues but I'm not sure how to find out what the real problem is let alone how to fix it.. I am running FreeBSD midget.dons.net.au 8.2-PRERELEASE FreeBSD 8.2- PRERELEASE #8 r217094M: Sat Jan 8 11:15:07 CST 2011 dar...@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 It is a 5 disk RAIDZ1 with 1.29Tb free using WD10EADS drives. I don't see any SMART errors or ZFS warnings. I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. Huh? I use values without quotes all the time in loader.conf. I've seen cases where entries in /boot/loader.conf throw parser errors during loader(8) when quotes aren't used. The man page denotes that quotes are required, which doesn't appear to be true? Possibly the parser only throws errors if non-numeric/non-integer values (e.g. strings) are specified without quotes. It's interesting that in the BUGS section of the man page the syntax shown for hw.ata.ata_dma=0 also violates the required syntax. So the question is: what's reality, and would better documentation suffice? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)
2011/4/28 Jack Vogel jfvo...@gmail.com: On Thu, Apr 28, 2011 at 2:28 PM, John Baldwin j...@freebsd.org wrote: On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: Though they mention that HT MSI windows is disabled. I'm not sure, whether this matters. Yes, that is probably what breaks this. -- John Baldwin Opps, missed that, thanks John. So, disable MSIX and MSI using sysctl, then the driver should use legacy when it loads. Still, I'd get a different motherboard, sucks to not have MSIX :( Thanks for hints. I've disabled MSIX and MSI: kadlubek# sysctl hw.pci | grep msi hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 0 hw.pci.enable_msi: 0 and reloaded if_em module. During initialization it confirmed, that will not use MSI(X): em0: Intel(R) PRO/1000 Network Connection 7.1.9 port 0xdc00-0xdc1f mem 0xfe9e-0xfe9f,0xfe90-0xfe97,0xfe9dc000-0xfe9d irq 24 at device 0.0 on pci2 em0: MSIX: insufficient vectors, using MSI em0: No MSI/MSIX using a Legacy IRQ em0: [FILTER] em0: Ethernet address: 00:1b:21:9d:52:1b em0: link state changed to UP Though behavior hasn't change - I still see outgoing packets, and no incoming traffic. As far as I see, linux driver does that automagically, when no MSI(-X) is available, then it fallbacks to IRQ: [ 16.377387] e1000e :02:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts. Falling back to MSI interrupts. [ 16.377511] e1000e :02:00.0: (unregistered net_device): Failed to initialize MSI interrupts. Falling back to legacy interrupts. Does anything come to your mind, that I can do, to debug, why this card is not working? Cheers, Wiktor ___ 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: ZFS vs OSX Time Machine
On Thu, Apr 28, 2011 at 11:59 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: I've seen cases where entries in /boot/loader.conf throw parser errors during loader(8) when quotes aren't used. The man page denotes that quotes are required, which doesn't appear to be true? Possibly the parser only throws errors if non-numeric/non-integer values (e.g. strings) are specified without quotes. It's interesting that in the BUGS section of the man page the syntax shown for hw.ata.ata_dma=0 also violates the required syntax. So the question is: what's reality, and would better documentation suffice? My reality: zfs_load=YES vfs.root.mountfrom=zfs:zroot vfs.root.mountfrom.options=rw vfs.zfs.debug=1 geom_mirror_load=YES ahci_load=YES ... works. And I've used even more sloppy syntax on occasion, basically I've left out quotes on pretty much all values which are pure alphanumeric. loader.conf(5) does say: All settings have the following format: variable=value but it also says it's format was defined explicitly to resemble rc.conf(5) and can be sourced by sh(1), which should mean that quoting is not required anywhere. If you read that literally, you should even be able to do this in loader.conf: some_value=VALUE\ WITH\ SPACES ... because that can be sourced by sh(1) and would result in some_value='VALUE WITH SPACES', but I haven't tried rebooting a machine with such settings in loader.conf yet and I wouldn't bet on it working nor would I actually use such madness in loader.conf even if I could. -- Mikael ___ 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
[releng_8 tinderbox] failure on ia64/ia64
TB --- 2011-04-28 21:26:53 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-04-28 21:26:53 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2011-04-28 21:26:53 - cleaning the object tree TB --- 2011-04-28 21:27:10 - cvsupping the source tree TB --- 2011-04-28 21:27:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2011-04-28 21:27:42 - building world TB --- 2011-04-28 21:27:42 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-28 21:27:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-28 21:27:42 - TARGET=ia64 TB --- 2011-04-28 21:27:42 - TARGET_ARCH=ia64 TB --- 2011-04-28 21:27:42 - TZ=UTC TB --- 2011-04-28 21:27:42 - __MAKE_CONF=/dev/null TB --- 2011-04-28 21:27:42 - cd /src TB --- 2011-04-28 21:27:42 - /usr/bin/make -B buildworld World build started on Thu Apr 28 21:27:43 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.sbin/uhsoctl/uhsoctl.1 uhsoctl.1.gz === usr.sbin/usbdump (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-28 23:04:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-28 23:04:28 - ERROR: failed to build world TB --- 2011-04-28 23:04:28 - 4070.73 user 440.80 system 5854.84 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full ___ 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
[releng_8 tinderbox] failure on mips/mips
TB --- 2011-04-28 22:26:40 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2011-04-28 22:26:40 - starting RELENG_8 tinderbox run for mips/mips TB --- 2011-04-28 22:26:40 - cleaning the object tree TB --- 2011-04-28 22:26:51 - cvsupping the source tree TB --- 2011-04-28 22:26:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2011-04-28 22:27:25 - building world TB --- 2011-04-28 22:27:25 - MAKEOBJDIRPREFIX=/obj TB --- 2011-04-28 22:27:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-04-28 22:27:25 - TARGET=mips TB --- 2011-04-28 22:27:25 - TARGET_ARCH=mips TB --- 2011-04-28 22:27:25 - TZ=UTC TB --- 2011-04-28 22:27:25 - __MAKE_CONF=/dev/null TB --- 2011-04-28 22:27:25 - cd /src TB --- 2011-04-28 22:27:25 - /usr/bin/make -B buildworld World build started on Thu Apr 28 22:27:26 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] gzip -cn /src/usr.sbin/uhsoctl/uhsoctl.1 uhsoctl.1.gz === usr.sbin/usbdump (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-04-28 23:29:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-04-28 23:29:52 - ERROR: failed to build world TB --- 2011-04-28 23:29:52 - 2348.38 user 376.27 system 3791.79 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full ___ 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: [releng_8 tinderbox] failure on arm/arm
On Thu, Apr 28, 2011 at 09:06:32PM +, FreeBSD Tinderbox wrote:
=== usr.sbin/usbdump (all)
cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c
/src/usr.sbin/usbdump/usbdump.c
cc1: warnings being treated as errors
/src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket':
/src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required
alignment of target type
/src/usr.sbin/usbdump/usbdump.c: In function 'print_packets':
/src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required
alignment of target type
*** Error code 1
Stop in /src/usr.sbin/usbdump.
*** Error code 1
CC'ing hselasky and thompsa for review of this.
For failure logs (so far ia64 and arm), please see end of this page:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html
Commit question is revision 1.6.2.2 to RELENG_8:
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/usbdump/usbdump.c
Relevant code bits:
290: static void
291: print_apacket(const struct bpf_xhdr *hdr, const uint8_t *ptr, int ptr_len)
292: {
...
349:const struct usbpf_framehdr *uf;
...
353:uf = (const struct usbpf_framehdr *)ptr;
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
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: ZFS vs OSX Time Machine
On 29/04/2011, at 2:16, Malcolm Waltz wrote: I doubt the issues you are encountering have much to do with ZFS. It sounds like you are using TimeMachine over NFS. Obviously, Apple does not support that configuration: http://www.google.com/search?q=time+machine+nfs+site:apple.com In my opinion, TimeMachine should only be used with block storage. If you use any kind of file-sharing protocol (AFP, SMB/CIFS or NFS), TimeMachine is implemented using a sparse disk image broken into hundreds or thousands of separate files. This is a hack at best. Time machine works very well with locally attached storage, but if you need to use network storage, you might want to try iSCSI: http://thegreyblog.blogspot.com/2010/02/using-zfs-with-apple-time-machine.html http://people.freebsd.org/~rse/iscsi/iscsi.txt Hmm, I _am_ using AFPD, not NFS for this.. I will see about using an ISCSI disk image instead (although that would make it impossible to resize once it's created right?) I see that the sparse disk image does use ~8 files in a single directory which does take.. a while.. to stat.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: ZFS vs OSX Time Machine
On 29/04/2011, at 5:26, Jeremy Chadwick wrote: I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. Yep, they're working :) I'm also not sure why you're setting cache_flush_disable at all. I think I was wondering if it would help the abysmal write performance of these disks.. Any help appreciated, thanks :) Others seem to be battling stating that NFS doesn't work for TM, but that isn't what you're complaining about. You're complaining that FreeBSD with ZFS + NFS performs extremely poorly when trying to do backups from an OS X client using TM (writing to the NFS mount). Yes, and also TM is over AFP not NFS (I forgot to mention that..) I have absolutely no experience with TM or OS X, so if it's actually a client-level problem (which I'm doubting) I can't help you there. Just sort of a ramble here at different things... It would be useful to provide ZFS ARC sysctl data from the FreeBSD system where you're seeing performance issues. sysctl -a kstat.zfs.misc.arcstats should suffice. kstat.zfs.misc.arcstats.hits: 236092077 kstat.zfs.misc.arcstats.misses: 6451964 kstat.zfs.misc.arcstats.demand_data_hits: 98087637 kstat.zfs.misc.arcstats.demand_data_misses: 1220891 kstat.zfs.misc.arcstats.demand_metadata_hits: 138004440 kstat.zfs.misc.arcstats.demand_metadata_misses: 5231073 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 15041670 kstat.zfs.misc.arcstats.mru_ghost_hits: 956048 kstat.zfs.misc.arcstats.mfu_hits: 221050407 kstat.zfs.misc.arcstats.mfu_ghost_hits: 3269042 kstat.zfs.misc.arcstats.allocated: 15785717 kstat.zfs.misc.arcstats.deleted: 4690878 kstat.zfs.misc.arcstats.stolen: 4990300 kstat.zfs.misc.arcstats.recycle_miss: 2142423 kstat.zfs.misc.arcstats.mutex_miss: 518 kstat.zfs.misc.arcstats.evict_skip: 2251705 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 470396116480 kstat.zfs.misc.arcstats.evict_l2_ineligible: 2048 kstat.zfs.misc.arcstats.hash_elements: 482679 kstat.zfs.misc.arcstats.hash_elements_max: 503063 kstat.zfs.misc.arcstats.hash_collisions: 19593315 kstat.zfs.misc.arcstats.hash_chains: 116103 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 1692798721 kstat.zfs.misc.arcstats.c: 3221225472 kstat.zfs.misc.arcstats.c_min: 402653184 kstat.zfs.misc.arcstats.c_max: 3221225472 kstat.zfs.misc.arcstats.size: 3221162968 kstat.zfs.misc.arcstats.hdr_size: 103492088 kstat.zfs.misc.arcstats.data_size: 2764591616 kstat.zfs.misc.arcstats.other_size: 353079264 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 19 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 1 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 You should also try executing zpool iostat -v 1 during the TM backup to see if there's a particular device which is behaving poorly. There have been reports of ZFS pools behaving poorly when a single device within the pool has slow I/O (e.g. 5 hard disks, one of which has internal issues, resulting in the entire pool performing horribly). You should let this run for probably 60-120 seconds to get an idea. Given your parameters above (assuming vfs.zfs.txg.timeout IS in fact 5!), you should see bursts of writes every 5 seconds. OK. I know that
Re: [releng_8 tinderbox] failure on arm/arm
On 29 April 2011 11:30, Jeremy Chadwick free...@jdc.parodius.com wrote: On Thu, Apr 28, 2011 at 09:06:32PM +, FreeBSD Tinderbox wrote: === usr.sbin/usbdump (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/usbdump/usbdump.c cc1: warnings being treated as errors /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': /src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required alignment of target type /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': /src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/usbdump. *** Error code 1 CC'ing hselasky and thompsa for review of this. For failure logs (so far ia64 and arm), please see end of this page: http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html Commit question is revision 1.6.2.2 to RELENG_8: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/usbdump/usbdump.c Relevant code bits: I merged the missing rev a few hours ago, http://svnweb.freebsd.org/base?view=revisionrevision=221185 Andrew ___ 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: ZFS vs OSX Time Machine
On Fri, Apr 29, 2011 at 09:43:47AM +0930, Daniel O'Connor wrote: On 29/04/2011, at 5:26, Jeremy Chadwick wrote: I have the following ZFS related tunables vfs.zfs.arc_max=3072M vfs.zfs.prefetch_disable=1 vfs.zfs.txg.timeout=5 vfs.zfs.cache_flush_disable=1 Are the last two actually *working* in /boot/loader.conf? Can you verify by looking at them via sysctl? AFAIK they shouldn't work, since they lack double-quotes around the values. Parsing errors are supposed to throw you back to the loader prompt. See loader.conf(5) for the syntax. Yep, they're working :) I'm also not sure why you're setting cache_flush_disable at all. I think I was wondering if it would help the abysmal write performance of these disks.. Any help appreciated, thanks :) Others seem to be battling stating that NFS doesn't work for TM, but that isn't what you're complaining about. You're complaining that FreeBSD with ZFS + NFS performs extremely poorly when trying to do backups from an OS X client using TM (writing to the NFS mount). Yes, and also TM is over AFP not NFS (I forgot to mention that..) I have absolutely no experience with TM or OS X, so if it's actually a client-level problem (which I'm doubting) I can't help you there. Just sort of a ramble here at different things... It would be useful to provide ZFS ARC sysctl data from the FreeBSD system where you're seeing performance issues. sysctl -a kstat.zfs.misc.arcstats should suffice. kstat.zfs.misc.arcstats.hits: 236092077 kstat.zfs.misc.arcstats.misses: 6451964 kstat.zfs.misc.arcstats.demand_data_hits: 98087637 kstat.zfs.misc.arcstats.demand_data_misses: 1220891 kstat.zfs.misc.arcstats.demand_metadata_hits: 138004440 kstat.zfs.misc.arcstats.demand_metadata_misses: 5231073 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 15041670 kstat.zfs.misc.arcstats.mru_ghost_hits: 956048 kstat.zfs.misc.arcstats.mfu_hits: 221050407 kstat.zfs.misc.arcstats.mfu_ghost_hits: 3269042 kstat.zfs.misc.arcstats.allocated: 15785717 kstat.zfs.misc.arcstats.deleted: 4690878 kstat.zfs.misc.arcstats.stolen: 4990300 kstat.zfs.misc.arcstats.recycle_miss: 2142423 kstat.zfs.misc.arcstats.mutex_miss: 518 kstat.zfs.misc.arcstats.evict_skip: 2251705 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 470396116480 kstat.zfs.misc.arcstats.evict_l2_ineligible: 2048 kstat.zfs.misc.arcstats.hash_elements: 482679 kstat.zfs.misc.arcstats.hash_elements_max: 503063 kstat.zfs.misc.arcstats.hash_collisions: 19593315 kstat.zfs.misc.arcstats.hash_chains: 116103 kstat.zfs.misc.arcstats.hash_chain_max: 16 kstat.zfs.misc.arcstats.p: 1692798721 kstat.zfs.misc.arcstats.c: 3221225472 kstat.zfs.misc.arcstats.c_min: 402653184 kstat.zfs.misc.arcstats.c_max: 3221225472 kstat.zfs.misc.arcstats.size: 3221162968 kstat.zfs.misc.arcstats.hdr_size: 103492088 kstat.zfs.misc.arcstats.data_size: 2764591616 kstat.zfs.misc.arcstats.other_size: 353079264 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 19 kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 1 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 Thanks. I don't see anything indicative here of ARC problems. memory_throttle_count being 19 is acceptable as well (though a very large number could indicate issues of a different sort). Otherwise things look very good/normal. You should also try executing zpool iostat -v 1 during the TM backup to see if there's a particular device which is behaving poorly. There have been
Re: ZFS vs OSX Time Machine
ZFS volumes (zvol s) can definitely be resized using the volsize property: # zfs get volsize mypool/myvol NAMEPROPERTY VALUESOURCE mypool/myvol volsize 2G - # zfs set volsize=4g mypool/myvol Mac OS 10.5 and later allows you to resize Journaled HFS+ volumes (using diskutil or Disk Utility.app). Doing a quick google search, I see plenty of references to decreasing the size of a TimeMachine volume, so it's probably possible to increase it as well. I'm sure you can find more with a little googleing. man diskutil (look for resizeVolume) indicates that you can increase and decrease the size and doesn't mention anything special about Time Machine. On Apr 28, 2011, at 5:02 PM, Daniel O'Connor wrote: On 29/04/2011, at 2:16, Malcolm Waltz wrote: I doubt the issues you are encountering have much to do with ZFS. It sounds like you are using TimeMachine over NFS. Obviously, Apple does not support that configuration: http://www.google.com/search?q=time+machine+nfs+site:apple.com In my opinion, TimeMachine should only be used with block storage. If you use any kind of file-sharing protocol (AFP, SMB/CIFS or NFS), TimeMachine is implemented using a sparse disk image broken into hundreds or thousands of separate files. This is a hack at best. Time machine works very well with locally attached storage, but if you need to use network storage, you might want to try iSCSI: http://thegreyblog.blogspot.com/2010/02/using-zfs-with-apple-time-machine.html http://people.freebsd.org/~rse/iscsi/iscsi.txt Hmm, I _am_ using AFPD, not NFS for this.. I will see about using an ISCSI disk image instead (although that would make it impossible to resize once it's created right?) I see that the sparse disk image does use ~8 files in a single directory which does take.. a while.. to stat.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: ZFS vs OSX Time Machine
On Apr 28, 2011, at 6:08 PM, Jeremy Chadwick wrote: Be aware there are all sorts of caveats/complexities with iSCSI on FreeBSD. There are past threads on -stable and -fs talking about them in great detail. I personally wouldn't go this route. Why can't OS X use CIFS? It has the ability to mount a SMB filesystem, right? Is there some reason you can't mount that, then tell TM to write its backups to /mountedcifs? Ahh... I see. Well this works perfectly (iSCSI on ZFS): http://www.nexenta.org/ Perhaps we will see some improvements in the future. As for CIFS, yes some people do that. I wouldn't, but whatever. Certainly you won't see _better_ performance. Most people choose AFP for this (as did the original poster). http://www.nickebo.net/tag/benchmark/ (there are plenty of others) As you can read in my previous posts, Time Machine needs block storage. If you don't use block storage, it will emulate block storage using a disk image, which in this case is generating ~8 files in one directory (sparse-bands). Good luck with that. If iSCSI is not stable on FreeBSD, then it's probably best not to store Time Machine data on FreeBSD. Some people don't seem to have issues with this (as one other poster mentioned). I suppose it depends on how much and what kind of data you are backing up. I can say that if you are backing up a media library and other normal user data using Time Machine, it definitely performs poorly (unusable) after a while if you are using anything but block based storage. If it hasn't happened to you yet, just wait. It will. ___ 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: ZFS vs OSX Time Machine
On Thu, Apr 28, 2011 at 6:08 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: I will note something, however: your ARC max is set to 3072MB, yet Wired is around 4143MB. Do you have something running on this box that takes up a lot of RAM? mysqld, etc..? I'm trying to account for the extra gigabyte in Wired. top -o res might help here, but we'd need to see the process list. I'm thinking something else on your machine is also taking up Wired, because your arcstats shows: kstat.zfs.misc.arcstats.c: 3221225472 kstat.zfs.misc.arcstats.c_min: 402653184 kstat.zfs.misc.arcstats.c_max: 3221225472 kstat.zfs.misc.arcstats.size: 3221162968 Which is about 3072MB (there is always some degree of variance). The difference is probably due to fragmentation (most of ARC allocations are served from power-of-2 zones, if I'm not mistaken) + a lot of wired memory sits in slab allocator caches (FREE column in vmstat -z). On a system with ARC size of ~16G I regularly see ~22GB wired. Ona smaller box I get about 7GB wired at around 5.5GB ARC size. --Artem ___ 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: ZFS vs OSX Time Machine
On 29/04/2011, at 11:43, Artem Belevich wrote: On Thu, Apr 28, 2011 at 6:08 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: I will note something, however: your ARC max is set to 3072MB, yet Wired is around 4143MB. Do you have something running on this box that takes up a lot of RAM? mysqld, etc..? I'm trying to account for the extra gigabyte in Wired. top -o res might help here, but we'd need to see the process list. I'm thinking something else on your machine is also taking up Wired, because your arcstats shows: kstat.zfs.misc.arcstats.c: 3221225472 kstat.zfs.misc.arcstats.c_min: 402653184 kstat.zfs.misc.arcstats.c_max: 3221225472 kstat.zfs.misc.arcstats.size: 3221162968 Which is about 3072MB (there is always some degree of variance). The difference is probably due to fragmentation (most of ARC allocations are served from power-of-2 zones, if I'm not mistaken) + a lot of wired memory sits in slab allocator caches (FREE column in vmstat -z). On a system with ARC size of ~16G I regularly see ~22GB wired. Ona smaller box I get about 7GB wired at around 5.5GB ARC size. This system also does double duty as a desktop PC so it gets a fair hammering.. It did have 4GB of RAM but that was fairly terrible, 8GB is a lot better though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: MPS driver: force bus rescan after remove SAS cable
Jeremy: I don't mean to sound critical, but why do you guys do this? The reason I ask: on actual production filers (read: NetApps), you don't go yanking out the FC cable between the HBA and the NA and expect everything to be happy afterwards. Most SAN administrators tend to reboot an appliance when doing this kind of work -- because this kind of work is considered maintenance. I have just realized that I didn't respond with what I intended to. Sorry about that. What I meant to add to the discussion yesterday was that ejecting a single disk and plugging it back in does not cause (at least in my case) the block device to re-appear again. I haven't tried unplugging the whole cable/backplane. Don't see the point indeed. I understand what you folks are reporting is a problem. I'm just wondering why you're complaining about having to reboot a machine with an HBA in it after doing this kind of *physical* cabling work. My immediate thought is I'm really not surprised. I guess some other people *are* surprised. :-) Again I missed the point and didn't respond properly. Also identify function doesn't work from the OS (no problem via the card BIOS). Don't remember having any luck with sg3_util package either but worth trying again. I don't use SAS myself, but wouldn't the command be inquiry and not identify? identify is for ATA (specifically SATA via CAM), while inquiry is for SCSI. Where SAS fits into this is unknown to me. Well I have SATA disks visible as /dev/da* . From camcontrol(8): inquiry Send a SCSI inquiry command (0x12) to a device. By default, camcontrol will print out the standard inquiry data, device serial number, and transfer rate information. The user can specify that only certain types of inquiry data be printed: Example: # camcontrol inquiry /dev/da47 pass48: ATA WDC WD2003FYYS-0 0D02 Fixed Direct Access SCSI-5 device pass48: Serial Number WD-WMAUR0408496 pass48: 300.000MB/s transfers, Command Queueing Enabled It's a SATA disk in this case attached to SAS/SATA backplane and SAS2008 HBA chip (9211-8i) What I need is a way to light on the fault led on the disk that I want to identify (point to) This is usually what I need when I send a DC technician to replace a disk. For which I though I should be using: identifySend a ATA identify command (0xec) to a device. From my experience SAS or SATA disks - I always get those as /dev/da* disks. It's a combo controller and backplane. So which is the correct way of identifying a disk? On a related note: recently LSI released version 9.0 of their firmware for SAS2008 and I found it fixes certain performance problems with SuperMicro backplanes! In another thread, or a PR, if you could provide those technical details that would be beneficial. There are a very large number of FreeBSD users who use Supermicro server-class hardware, and I'm certain they would be interested in a full disclosure. What I meant was that it fixes problems not specific to FreeBSD. I don't have much more to add and don't think that a separate thread is required for this here (since it's not directly FreeBSD specific) but in a nutshell the issue that I was experiencing was that when I connect a 9211-8i to a 6Gbit/s SAS expander the performance/bandwidth was terrible and I couldn't get more than 200 MB/s of off the disk array in sequential access even when the disks were in a simple raid0 setup. With the release of version 9.0 everything is pretty good and am able to achieve gigabyte speeds in sequential access. Another bug they fixed which wasn't too bad but still ... is that each lane in a multilane cable (8087) to the backplane was reported as a separate connection so all the disks were visible 4 times (via 4 different expanders) even though there's only 1 multilane cable connected to 1 backplane. Again both those are fixed in 9.0. I hope this helps. Cheers, -- Rumen Telbizov http://telbizov.com ___ 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: ZFS vs OSX Time Machine
On 29/04/2011, at 10:38, Jeremy Chadwick wrote: Could you please provide output from zfs get all poolname? Myself and others would like to review what settings you're using on the filesystem. If it's a separate filesystem (e.g. pool/foobar), please also provide output from zfs get all pool. [midget 11:51] ~ zfs get all tank NAME PROPERTY VALUE SOURCE tank type filesystem - tank creation Thu Sep 24 11:22 2009 - tank used 2.58T - tank available 981G - tank referenced44.7K - tank compressratio 1.00x - tank mounted yes- tank quota none default tank reservation none default tank recordsize128K default tank mountpoint/tank default tank sharenfs offdefault tank checksum on default tank compression offdefault tank atime on default tank devices on default tank exec on default tank setuidon default tank readonly offdefault tank jailedoffdefault tank snapdir hidden default tank aclmode groupmask default tank aclinheritrestricted default tank canmount on default tank shareiscsioffdefault tank xattr offtemporary tank copies1 default tank version 3 - tank utf8only off- tank normalization none - tank casesensitivity sensitive - tank vscan offdefault tank nbmandoffdefault tank sharesmb offdefault tank refquota none default tank refreservationnone default tank primarycache alldefault tank secondarycachealldefault tank usedbysnapshots 0 - tank usedbydataset 44.7K - tank usedbychildren2.58T - tank usedbyrefreservation 0 - [midget 11:51] ~ zfs get all tank/TimeMachine NAME PROPERTY VALUE SOURCE tank/TimeMachine type filesystem - tank/TimeMachine creation Sat May 8 10:59 2010 - tank/TimeMachine used 555G - tank/TimeMachine available 45.3G - tank/TimeMachine referenced555G - tank/TimeMachine compressratio 1.00x - tank/TimeMachine mounted yes- tank/TimeMachine quota 600G local tank/TimeMachine reservation none default tank/TimeMachine recordsize128K default tank/TimeMachine mountpoint/tank/TimeMachine default tank/TimeMachine sharenfs offdefault tank/TimeMachine checksum on default tank/TimeMachine compression offdefault tank/TimeMachine atime on default tank/TimeMachine devices on default tank/TimeMachine exec on default tank/TimeMachine setuidon default tank/TimeMachine readonly offdefault tank/TimeMachine jailedoffdefault tank/TimeMachine snapdir hidden default tank/TimeMachine aclmode groupmask default tank/TimeMachine aclinheritrestricted default tank/TimeMachine canmount on default tank/TimeMachine shareiscsioffdefault tank/TimeMachine xattr offtemporary tank/TimeMachine copies1 default tank/TimeMachine version 3 - tank/TimeMachine utf8only off- tank/TimeMachine normalization none - tank/TimeMachine
Re: panic, but /var/crash ist empty
On Wed, Apr 27, 2011 at 1:44 PM, Helmut Schneider jumpe...@gmx.de wrote: Hi, running 8.2-RELEASE-p1 within VMWare ESXi 4.1-u1 I want to use raw devices as hard disks. I create the devices using this link: http://www.mattiasholm.com/node/33 I tried 3 different hard drives (Seagate 2x80GB and 1x400GB SATA2) which are fine on a physical machine. I also ran Seatool many hours on all of them without errors. I can partiton the disks and create a few files/directories on it. But as soon as I copy a larger number of files to those disks (tried with MBR and GPT) the VM reboots *instantly* (I tried cp, dump/restore and rsync). No Rebooting within 15 seconds, just *snap*. I think I can see an panic but I'm not sure, it's too fast. (as far as I can see most of the times the data on the first UFS slice (and only the first UFS slice!) of the partition gets *severly* corrupted, most of the time all that is left are a few files within lost+found. Sometimes all the labels are gone but are recoverable using bsdlabel -R) The problem is that /var/crash remains empty. What can I do to create a backtrace to open a PR? Thanks, Helmut Hi Helmut, To get a backtrace from the crash (or drop to the debugger), you'll need to compile a kernel with at least a couple of options defined. These two: options KDB options DDB ...will allow you to work with the debugger on the console after a crash. Further, with the option KDB_TRACE in the kernel config, you'll get a backtrace printed automatically when the kernel panicsb. Here are a couple of excellent documents to read to get you started: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Kernel debug options: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html ___ 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: MPS driver: force bus rescan after remove SAS cable
Rumen Telbizov wrote: Also identify function doesn't work from the OS (no problem via the card BIOS). Don't remember having any luck with sg3_util package either but worth trying again. I don't use SAS myself, but wouldn't the command be inquiry and not identify? identify is for ATA (specifically SATA via CAM), while inquiry is for SCSI. Where SAS fits into this is unknown to me. Well I have SATA disks visible as /dev/da* . From camcontrol(8): inquiry Send a SCSI inquiry command (0x12) to a device. By default, camcontrol will print out the standard inquiry data, device serial number, and transfer rate information. The user can specify that only certain types of inquiry data be printed: Example: # camcontrol inquiry /dev/da47 pass48: ATA WDC WD2003FYYS-0 0D02 Fixed Direct Access SCSI-5 device pass48: Serial Number WD-WMAUR0408496 pass48: 300.000MB/s transfers, Command Queueing Enabled It's a SATA disk in this case attached to SAS/SATA backplane and SAS2008 HBA chip (9211-8i) What I need is a way to light on the fault led on the disk that I want to identify (point to) This is usually what I need when I send a DC technician to replace a disk. For which I though I should be using: identifySend a ATA identify command (0xec) to a device. From my experience SAS or SATA disks - I always get those as /dev/da* disks. It's a combo controller and backplane. So which is the correct way of identifying a disk? `camcontrol identify` means sending ATA IDENTIFY DEVICE command to the ATA device. That command is roughly the analogue of the SCSI INQUIRY command. It has nothing to do with LEDs. LEDs most likely controlled via ses device or some alike management thing. The fact that you see ATA device as daX is just means that your SAS controller does protocol translation on-the-fly. It allows you to communicate with disk using SCSI commands _instead_ of ATA. -- Alexander Motin ___ 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
