Re: Depreciate and remove gbde
On Thu, 29 Oct 2015 16:24:00 -0700, John-Mark Gurney wrote: > Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700: > > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > > > > > The thing I like most about encryption is that when I RMA a bad > > > drive, I don't have to worry about my data leaking if I am unable > > > to overwrite all the data... > > > > You are optimistic if you believe that. We ($WORK) factor the cost of > > DOA/warranty drives into our operational budget. They never get RMAed. We > > drill them when they die. > > Being a personal user, and having close to a 10% RMA rate on recent > hard drives, that would be a bit costly... > > I consider a HD defective if it's under waranty and it's performance > drops below 80% of new, i.e. 130MB/sec normal sequential write drops > below 100MB/sec.. > > The weekest point is the passphrase/passfile protecting the master > key... In my case, I use a random passfile for these drives... If > someone is able to break the passfile, or the AES-256 encryption, then > they must really want my data... It'd be easier, even for governments, > to do a black bag job than recover partial data (it's one drive of a > RAIDZ array)... > > -- > John-Mark GurneyVoice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" FWIW I've several WD eide that corrupt with twed0... fix them with dosdlg.exe on floppy (long test, an hour...) and they work fine as primary eide drives a long while thereafter (not secondary on twed0...) in case that saves anyone some time/money... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700: > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney wrote: > > > The thing I like most about encryption is that when I RMA a bad > > drive, I don't have to worry about my data leaking if I am unable > > to overwrite all the data... > > You are optimistic if you believe that. We ($WORK) factor the cost of > DOA/warranty drives into our operational budget. They never get RMAed. We > drill them when they die. Being a personal user, and having close to a 10% RMA rate on recent hard drives, that would be a bit costly... I consider a HD defective if it's under waranty and it's performance drops below 80% of new, i.e. 130MB/sec normal sequential write drops below 100MB/sec.. The weekest point is the passphrase/passfile protecting the master key... In my case, I use a random passfile for these drives... If someone is able to break the passfile, or the AES-256 encryption, then they must really want my data... It'd be easier, even for governments, to do a black bag job than recover partial data (it's one drive of a RAIDZ array)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288951: ifconfig -alias, arp not removed
On 10/29/2015 9:46 AM, Bryan Drewery wrote: > On 10/29/15 9:42 AM, Eric van Gyzen wrote: >> On 10/29/2015 11:25, Bryan Drewery wrote: >>> # ifconfig >>> igb0: flags=8843 metric 0 mtu 1500 >>> >>> options=403bb >>> ether c8:0a:a9:04:39:78 >>> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 >>> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 >>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 >>> nd6 options=23 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> # ifconfig igb0 inet 10.10.0.9 -alias >>> # arp -an|grep 10.10.0.9 >>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >>> # arp -d 10.10.0.9 >>> arp: writing to routing socket: Operation not permitted >>> >>> I swear this is not normal. I'm on an older build as well, r288951. >> >> That definitely looks abnormal. See what "route get" says. I think >> that's the error you get when there is a route for that address. >> > > # netstat -rn|grep 10.10.0.9 > # route get 10.10.0.9 >route to: lapbox > destination: 10.10.0.0 >mask: 255.255.0.0 > fib: 0 > interface: igb0 > flags: > recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >0 0 0 0 1500 1 0 > # route get 5.5.5.5 >route to: 5.5.5.5 > destination: default >mask: default > gateway: router.asus.com > fib: 0 > interface: igb0 > flags: > recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >0 0 0 0 1500 1 0 > > For more context, this current system had 10.10.0.9 added to it. I > started up a VM which also started using 10.10.0.9 and managed to "win" > on the local network for owning it. (I don't know arp and this stuff > well). I then came to this system to remove the alias and the arp entry > to allow me to connect from it and have gotten into this situation. > Just saw this in dmesg, which is what I described: arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0! arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9 on igb0 -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: r288951: ifconfig -alias, arp not removed
On 10/29/15 9:42 AM, Eric van Gyzen wrote: > On 10/29/2015 11:25, Bryan Drewery wrote: >> # ifconfig >> igb0: flags=8843 metric 0 mtu 1500 >> >> options=403bb >> ether c8:0a:a9:04:39:78 >> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 >> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 >> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 >> nd6 options=23 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> # ifconfig igb0 inet 10.10.0.9 -alias >> # arp -an|grep 10.10.0.9 >> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] >> # arp -d 10.10.0.9 >> arp: writing to routing socket: Operation not permitted >> >> I swear this is not normal. I'm on an older build as well, r288951. > > That definitely looks abnormal. See what "route get" says. I think > that's the error you get when there is a route for that address. > # netstat -rn|grep 10.10.0.9 # route get 10.10.0.9 route to: lapbox destination: 10.10.0.0 mask: 255.255.0.0 fib: 0 interface: igb0 flags: recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 1500 1 0 # route get 5.5.5.5 route to: 5.5.5.5 destination: default mask: default gateway: router.asus.com fib: 0 interface: igb0 flags: recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 1500 1 0 For more context, this current system had 10.10.0.9 added to it. I started up a VM which also started using 10.10.0.9 and managed to "win" on the local network for owning it. (I don't know arp and this stuff well). I then came to this system to remove the alias and the arp entry to allow me to connect from it and have gotten into this situation. -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r288951: ifconfig -alias, arp not removed
On 10/29/2015 11:25, Bryan Drewery wrote: > # ifconfig > igb0: flags=8843 metric 0 mtu 1500 > > options=403bb > ether c8:0a:a9:04:39:78 > inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 > inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 > inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 > nd6 options=23 > media: Ethernet autoselect (1000baseT ) > status: active > > # ifconfig igb0 inet 10.10.0.9 -alias > # arp -an|grep 10.10.0.9 > ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] > # arp -d 10.10.0.9 > arp: writing to routing socket: Operation not permitted > > I swear this is not normal. I'm on an older build as well, r288951. That definitely looks abnormal. See what "route get" says. I think that's the error you get when there is a route for that address. Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r288951: ifconfig -alias, arp not removed
# ifconfig igb0: flags=8843 metric 0 mtu 1500 options=403bb ether c8:0a:a9:04:39:78 inet 10.10.0.7 netmask 0x broadcast 10.10.255.255 inet 10.10.7.2 netmask 0x broadcast 10.10.255.255 inet 10.10.0.9 netmask 0x broadcast 10.10.255.255 nd6 options=23 media: Ethernet autoselect (1000baseT ) status: active # ifconfig igb0 inet 10.10.0.9 -alias # arp -an|grep 10.10.0.9 ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet] # arp -d 10.10.0.9 arp: writing to routing socket: Operation not permitted I swear this is not normal. I'm on an older build as well, r288951. -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS-related panic: "possible" spa->spa_errlog_lock deadlock
Fabian Keil wrote: > Xin Li wrote: > > > On 9/7/14 11:23 PM, Fabian Keil wrote: > > > Xin Li wrote: > > > > > >> On 9/7/14 9:02 PM, Fabian Keil wrote: > > >>> Using a kernel built from FreeBSD 11.0-CURRENT r271182 I got > > >>> the following panic yesterday: > > >>> > > >>> [...] Unread portion of the kernel message buffer: [6880] > > >>> panic: deadlkres: possible deadlock detected for > > >>> 0xf80015289490, blocked for 1800503 ticks > > >> > > >> Any chance to get all backtraces (e.g. thread apply all bt full > > >> 16)? I think a different thread that held the lock have been > > >> blocked, probably related to your disconnected vdev. > > > > > > Output of "thread apply all bt full 16" is available at: > > > http://www.fabiankeil.de/tmp/freebsd/kgdb-output-spa_errlog_lock-deadlock.txt > > > > > > A lot of the backtraces prematurely end with "Cannot access memory > > > at address", therefore I also added "thread apply all bt" output. > > > > > > Apparently there are at least two additional threads blocking below > > > spa_get_stats(): > [...] > > Yes, thread 1182 owned the lock and is waiting for the zio be done. > > Other threads that wanted the lock would have to wait. > > > > I don't have much clue why the system entered this state, however, as > > the operations should have errored out (the GELI device is gone on > > 21:44:56 based on your log, which suggests all references were closed) > > instead of waiting. > I finally found the time to analyse the problem which seems > to be that spa_sync() requires at least one writeable vdev to > complete, but holds the lock(s) required to remove or bring back > vdevs. > > Letting spa_sync() drop the lock and wait for at least one vdev > to become writeable again seems to make the problem unreproducible > for me, but probably merely shrinks the race window and thus is not > a complete solution. > > For details see: > https://www.fabiankeil.de/sourcecode/electrobsd/ZFS-Optionally-let-spa_sync-wait-for-writable-vdev.diff Patch updated to unbreak the userspace build and to note that the deadlock can still be reproduced with an artifical test case like: Shell 1: mdconfig -u 0 -f /dpool/scratch/test-vdev.img zpool create test /dev/md0 while sleep 1; do mdconfig -d -u 0 -o force && mdconfig -f /dpool/scratch/test-vdev.img && zpool clear test; done Shell 2: # Cause writes to the pool from another shell, for example # by creating datasets. Log excerpt (from test begin to deadlock): Oct 29 12:34:28 kendra ZFS: vdev state changed, pool_guid=16039353738236808887 vdev_guid=3080051161477470469 [...] Oct 29 12:46:57 kendra ZFS: vdev state changed, pool_guid=16039353738236808887 vdev_guid=3080051161477470469 Oct 29 12:46:59 kendra ZFS: vdev is removed, pool_guid=16039353738236808887 vdev_guid=3080051161477470469 Oct 29 12:46:59 kendra ZFS: vdev state changed, pool_guid=16039353738236808887 vdev_guid=3080051161477470469 Oct 29 12:47:00 kendra kernel: g_dev_taste: make_dev_p() failed (gp->name=md0, error=17) With the deadman enabled, this will also cause: panic: I/O to pool 'test' appears to be hung on vdev guid 3080051161477470469 at '/dev/md0'. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01136af870 vpanic() at vpanic+0x182/frame 0xfe01136af8f0 panic() at panic+0x43/frame 0xfe01136af950 vdev_deadman() at vdev_deadman+0x127/frame 0xfe01136af9a0 vdev_deadman() at vdev_deadman+0x40/frame 0xfe01136af9f0 spa_deadman() at spa_deadman+0x86/frame 0xfe01136afa20 softclock_call_cc() at softclock_call_cc+0x1a3/frame 0xfe01136afaf0 softclock() at softclock+0x94/frame 0xfe01136afb20 intr_event_execute_handlers() at intr_event_execute_handlers+0x1b6/frame 0xfe01136afb60 ithread_loop() at ithread_loop+0xa6/frame 0xfe01136afbb0 fork_exit() at fork_exit+0x9c/frame 0xfe01136afbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe01136afbf0 With test's txg_sync_thread being the offender: (kgdb) tid 101874 [Switching to thread 819 (Thread 101874)]#0 sched_switch (td=0xf800513649a0, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1969 1969cpuid = PCPU_GET(cpuid); (kgdb) where #0 sched_switch (td=0xf800513649a0, newtd=, flags=) at /usr/src/sys/kern/sched_ule.c:1969 #1 0x805a3a18 in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:470 #2 0x805ea15a in sleepq_wait (wchan=0x0, pri=0) at /usr/src/sys/kern/subr_sleepqueue.c:631 #3 0x80530509 in _cv_wait (cvp=0xf8002678ea98, lock=0xf8002678ea78) at /usr/src/sys/kern/kern_condvar.c:139 #4 0x81930bbb in zio_wait (zio=) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1535 #5 0x818e4871 in dsl_pool_sync (dp=0xf80047dfd000, txg=76) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:540 #6 0x
