Re: zfs on geli vs. geli on zfs (via zvol)
2011/7/1 Todd Wasson t...@duke.edu: Thanks to both C. P. and Pete for your responses. Comments inline: Case 1.) is probably harmless, because geli would return a corrupted sectors' content to zfs... which zfs will likely detect because it wouldn't checksum correctly. So zfs will correct it out of redundant storage, and write it back through a new encryption. BE CAREFUL: don't enable hmac integrity checks in geli, as that would prevent geli from returning corrupted data and would result in hangs! Perhaps the hmac integrity checks were related to the lack of reporting of problems back to zfs that Pete referred to? Maybe we need someone with more technical experience with the filesystem / disk access infrastructure to weigh in, but it still doesn't seem clear to me what the best option is. Case 2.) is a bigger problem. If a sector containing vital geli metadata (perhaps portions of keys?) gets corrupted, and geli had no way to detect and/or correct this (e.g. by using redundant sectors on the same .eli volume!), the whole .eli, or maybe some stripes out of it, could become useless. ZFS couldn't repair this at all... at least not automatically. You'll have to MANUALLY reformat the failed .eli device, and resilver it from zfs redundant storage later. This is precisely the kind of thing that made me think about putting zfs directly on the disks instead of geli... This, and other unknown issues that could crop up and are out of geli's ability to guard against. Agree. If you wanna have encrypted ZFS it's better to wait until zpool version 30 (which supports encryption) will be ported to FreeBSD. --- wbr, Nickolas ___ 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: Crashes with Promise controller
On Thu, Jun 30, 2011 at 6:31 PM, Christian Baer christian.b...@uni-dortmund.de wrote: A serial console is easy enough to set up on a Sun for example, but in this case, I am running a simple AthlonXP, which has nothing for that sort of help. I would need a special card for that and those cose quite a bit. :-( Not that special - you just need a serial port on two computers. If your computers don't have serial ports, USB serial adapters work fine, and are cheap, as are (single port) PCI serial cards. Alternatively, if both computers have firewire ports, you can use dcons, and all you need is a cable. 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
scp: Write Failed: Cannot allocate memory
Hello, I'm running 8.2-RELEASE and am having new problems with scp. When scping files to a ZFS directory on the FreeBSD server -- most notably large files -- the transfer frequently dies after just a few seconds. In my last test, I tried to scp an 800mb file to the FreeBSD system and the transfer died after 200mb. It completely copied the next 4 times I tried, and then died again on the next attempt. On the client side: Connection to home closed by remote host. lost connection In /var/log/auth.log: Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot allocate memory I've never seen this before and have used scp before to transfer large files without problems. This computer has been used in production for months and has a current uptime of 36 days. I have not been able to notice any problems copying files to the server via samba or netatalk, or any problems in apache. Uname: FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 EST 2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64 I've attached my dmesg and output of vmstat -z. I have not restarted the sshd daemon or rebooted the computer. Am glad to provide any other information or test anything else. Thanks, Scott # vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208,0, 205, 16, 205,0 UMA Zones:704,0, 205,0, 205,0 UMA Slabs:568,0,69503,32711, 72942509,0 UMA RCntSlabs:568,0, 4667, 583, 5664,0 UMA Hash: 256,0, 79, 11, 81,0 16 Bucket:152,0, 85, 165, 227,0 32 Bucket:280,0, 238, 196, 442,1 64 Bucket:536,0, 359, 222, 721, 126 128 Bucket: 1048,0, 5867,1,45296, 196701 VM OBJECT:216,0,26698,27140, 40712912,0 MAP: 232,0,7, 25,7,0 KMAP ENTRY: 120, 412734,15244, 3201, 200399669,0 MAP ENTRY:120,0,10795, 7557, 64096457,0 DP fakepg:120,0,0,0,0,0 SG fakepg:120,0,0,0,0,0 mt_zone: 2056,0, 278,1, 278,0 16:16,0,88568, 153688, 1913750912,0 32:32,0, 3825,12032, 260796507,0 64:64,0,70106, 195950, 21507520870, 0 128: 128,0, 428518, 337836, 3162416717,0 256: 256,0,47071, 197099, 517289563,0 512: 512,0, 593921, 656853, 563338488,0 1024:1024,0, 7190,18422, 25604261,0 2048:2048,0, 5271, 5559, 7565792,0 4096:4096,0, 3344, 2030, 57255230,0 Files: 80,0, 1603, 2312, 52443448,0 TURNSTILE:136,0, 2515, 265, 2545,0 umtx pi: 96,0,0,0,0,0 MAC labels:40,0,0,0,0,0 PROC:1120,0, 112, 1544, 1117378,0 THREAD: 1112,0, 1932, 582, 3101,0 SLEEPQUEUE:80,0, 2515, 298, 2545,0 VMSPACE: 392,0, 86, 784, 1118412,0 cpuset:72,0,2, 98,2,0 audit_record: 952,0,0,0,0,0 mbuf_packet: 256,0, 1024, 3584, 218220869,0 mbuf: 256,0,1, 3461, 562735494,0 mbuf_cluster:2048,25600, 4608, 1008, 5632,0 mbuf_jumbo_page: 4096,12800,0, 1859, 50017085,0 mbuf_jumbo_9k: 9216, 6400,0,0,0,0 mbuf_jumbo_16k: 16384, 3200,0,0,0,0 mbuf_ext_refcnt:4,0,0, 3024, 6978,0 g_bio:232,0,0, 2480, 492271394,0 ttyinq: 160,0, 135, 801, 2205,0 ttyoutq: 256,0, 72, 483, 1176,0 ata_request: 320,0,0,0,
Re: scp: Write Failed: Cannot allocate memory
On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote:
I'm running 8.2-RELEASE and am having new problems with scp. When scping
files to a ZFS directory on the FreeBSD server -- most notably large files
-- the transfer frequently dies after just a few seconds. In my last test, I
tried to scp an 800mb file to the FreeBSD system and the transfer died after
200mb. It completely copied the next 4 times I tried, and then died again on
the next attempt.
On the client side:
Connection to home closed by remote host.
lost connection
In /var/log/auth.log:
Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write failed: Cannot allocate
memory
I've never seen this before and have used scp before to transfer large files
without problems. This computer has been used in production for months and
has a current uptime of 36 days. I have not been able to notice any problems
copying files to the server via samba or netatalk, or any problems in
apache.
Uname:
FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat Feb 19 01:02:54 EST
2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64
I've attached my dmesg and output of vmstat -z.
I have not restarted the sshd daemon or rebooted the computer.
Am glad to provide any other information or test anything else.
{snip vmstat -z and dmesg}
You didn't provide details about your networking setup (rc.conf,
ifconfig -a, etc.). netstat -m would be useful too.
Next, please see this thread circa September 2010, titled Network
memory allocation failures:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708
The user in that thread is using rsync, which relies on scp by default.
I believe this problem is similar, if not identical, to yours.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| 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
libarchive, lzma, and xz interaction
I'm trying to understand the problems I am having on some systems regarding libarchive, lzma, and xz. I have an 8-Stable system updated yesterday. As far as I can tell, libarchive does include the lzma stuff from libzma. At least I see the references. But several ports seem to still pull in xz-5.0.1 and link to it. This has a wonderful potential to cause library symbol conflicts. I get: /usr/lib/libarchive.so: undefined reference to `lzma_stream_encoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_memusage@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_stream_decoder@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_code@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_end@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_lzma_preset@XZ_5.0' /usr/lib/libarchive.so: undefined reference to `lzma_alone_encoder@XZ_5.0' ldd shows libarchive linked against liblzma.so.5 and an objdump of the dynamic symbols from liblzma.so.5 shows the undefined symbols defined with the XZ_5.0 version, so I am mystified. It looks o me like it is there. Is confusion with xz-5.0.1 causing this? Should get rid of it? Even so, I don't understand why the loader is claiming that these symbols are undefined when they seem to be defined as far as I can tell. 7c60 gDF .text 0084 XZ_5.0 lzma_stream_encoder Any clues to what i happening would be greatly appreciated! -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: scp: Write Failed: Cannot allocate memory
On Sat, Jul 02, 2011 at 12:54:35AM -0400, jhell wrote: On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote: The user in that thread is using rsync, which relies on scp by default. I believe this problem is similar, if not identical, to yours. rsync(1) does not rely on scp(1) whatsoever but rsync(1) can be made to use ssh(1) instead of rsh(1) and I believe that is what Jeremy is stating here but correct me if I am wrong. It does use ssh(1) by default. My apologies; yep that is what I meant. It uses ssh(1) pipe for I/O transport. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | 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
