From owner-freebsd-fs@freebsd.org Sun Jun 25 02:03:50 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1D0BD8654F for ; Sun, 25 Jun 2017 02:03:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7460B7FE92 for ; Sun, 25 Jun 2017 02:03:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5P23oR8054320 for ; Sun, 25 Jun 2017 02:03:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220185] >> operator does not append in Fuse mounts Date: Sun, 25 Jun 2017 02:03:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cem@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 02:03:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220185 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |cem@freebsd.org Status|New |In Progress --- Comment #1 from Conrad Meyer --- I can reproduce this problem with lklfuse (ext4 image). Exact same steps as Ben provided. $ truss sh -c 'echo line4 >> test.txt' ... openat(AT_FDCWD,"test.txt",O_WRONLY|O_APPEND|O_CREAT,0666) =3D 3 (0x3) dup2(0x3,0x1) =3D 1 (0x1) close(3) =3D 0 (0x0) write(1,"line4\n",6) =3D 6 (0x6) >From lklfuse -o debug: unique: 2, opcode: LOOKUP (1), nodeid: 1, insize: 49, pid: 7005 LOOKUP /test.txt getattr /test.txt NODEID: 2 unique: 2, success, outsize: 136 unique: 3, opcode: OPEN (14), nodeid: 2, insize: 48, pid: 7005 open flags: 0x1 /test.txt open[0] flags: 0x1 /test.txt unique: 3, success, outsize: 32 // Flag 0x1 =3D=3D O_WRONLY. I'm not sure if FUSE clients are supposed to handle O_APPEND or if FUSE is supposed to emulate it on their behalf. Either way, it seems to be getting dropped. That said =E2=80=94 it doesn't look like UFS does anything specia= l with the APPEND flag either. After all, multiple file handles can reference the same vnode at different offsets. So the offset should be a property of the file handle, not the vnode. This suggests some higher layer is misbehaving; not individual FUSE filesystems. (Not really surprising, I know.) More from lklfuse -o debug: unique: 4, opcode: GETATTR (3), nodeid: 2, insize: 40, pid: 7005 getattr /test.txt unique: 4, success, outsize: 112 unique: 5, opcode: WRITE (16), nodeid: 2, insize: 70, pid: 7005 write[0] 6 bytes to 0 flags: 0x0 write[0] 6 bytes to 0 unique: 5, success, outsize: 24 // Note: "to 0" (offset 0), "flags: 0x0" (no IO_APPEND) That's a problem. kern_openat() installs O_APPEND from open(2) into the struct file referring= to test.txt. Then in vn_write(), f_flag means that ioflag has IO_APPEND added= .=20 This is passed into VOP_WRITE. What does fs/fuse do with that? Well, there's a check in fuse_write_biobackend() that sets the uio offset to the end of the file if that flag is present. Either we aren't hitting that path, or the uio's offset isn't getting communicated to fuse filesystems. VOP_WRITE -> fuse_vnop_write -> fuse_iop_dispatch(). From there we enter fuse_write_directbackend for IO_DIRECT uio's, or fuse_write_biobackend otherwise. The DIRECT backend completely ignores IO_APPEND. I'd guess we're not hitti= ng that path as the open did not use O_DIRECT. I'm pretty confused by what fuse_write_biobackend() is doing, but it looks = like it may be correct. Maybe we're seeing the DIRECT path. ...haha, yup. fuse_vnop_open(): 1147 /* 1148 * For WRONLY opens, force DIRECT_IO. This is necessa= ry 1149 * since writing a partial block through the buffer ca= che 1150 * will result in a read of the block and that read wo= n't 1151 * be allowed by the WRONLY open. 1152 */ 1153 if (fufh_type =3D=3D FUFH_WRONLY || 1154 (fvdat->flag & FN_DIRECTIO) !=3D 0) 1155 fuse_open_flags =3D FOPEN_DIRECT_IO; Sigh. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sun Jun 25 13:26:11 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9127D91842 for ; Sun, 25 Jun 2017 13:26:11 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 433BC6EDFB for ; Sun, 25 Jun 2017 13:26:10 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id C2D0567937; Sun, 25 Jun 2017 15:26:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 1OGoBKEeO-bT; Sun, 25 Jun 2017 15:25:57 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id E8F3567936; Sun, 25 Jun 2017 15:25:57 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 916DF508A1; Sun, 25 Jun 2017 15:25:57 +0200 (CEST) Message-ID: <594FB9E5.3060806@incore.de> Date: Sun, 25 Jun 2017 15:25:57 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Kirk McKusick CC: Konstantin Belousov , freebsd-fs@freebsd.org Subject: Re: ufs snapshot is sometimes corrupt on gjourneled partition References: <201706242203.v5OM3U2Q096283@chez.mckusick.com> In-Reply-To: <201706242203.v5OM3U2Q096283@chez.mckusick.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 13:26:12 -0000 Kirk McKusick wrote: >> Date: Sat, 24 Jun 2017 18:30:17 +0300 >> From: Konstantin Belousov >> To: Andreas Longwitz >> Subject: Re: ufs snapshot is sometimes corrupt on gjourneled partition >> >> On Fri, Jun 23, 2017 at 11:14:43AM +0200, Andreas Longwitz wrote: >>> I try to understand the cause for the "free inode" problem described in >>> https://lists.freebsd.org/pipermail/freebsd-fs/2013-November/018610.html >>> >>> I have setup a test server (FreeBSD 10.3-STABLE #4 r317936) with a >>> gjournaled partition for /home: >>> mount -t ufs | grep /home --> >>> /dev/mirror/gmsvt7p10.journal on /home (ufs, asynchronous, local, >>> noatime, gjournal) >> As the first thing to try, if you perform your tests on the raw >> partition without gjournal, does the problem stay around ? > > I concur that running your test without gjournal is the next test to try. > I think that your suspicion that there is a race condition with gjournal > is likely correct. And if that is true, then the problem will go away > when gjournal is taken out of the stack. The problem only accurs when gjournal is active (tunefs -J) independent of the three possible mount options I have tested: async, noasync, sync. For my test I prefer async mount option as stated in gjournal(8). Using soft updates instead of gjournal is ok in all cases. >>> My test creates one snapshot of /home (gets alway inode 4) and removes >>> this snapshot: >>> >>> for i in 1 2 3 4 5 6 7 8; do >>> echo "starting snaptest $i" >/dev/console >>> mount -u -o snapshot -o noatime -o async /home/.snap/fscktest /home >>> echo $(ls -ils /home/.snap/fscktest) >/dev/console >>> rm -f /home/.snap/fscktest >>> done >>> >>> I never have more than this one snapshot at work and during the test I >>> never have any other >>> user processes working on /home. A typical output looks like this: >>> >>> Jun 21 15:59:52 root: starting snaptest 1 >>> Jun 21 15:59:52 root: 4 26592 -r-------- 1 root operator 90762970240 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:53 root: starting snaptest 2 >>> Jun 21 15:59:53 root: 4 26592 -r-------- 1 root operator 90762970152 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:54 kernel: freeing inode /home/4 with 704 blocks >>> Jun 21 15:59:54 root: starting snaptest 3 >>> Jun 21 15:59:54 kernel: free inode /home/4 had 704 blocks >>> Jun 21 15:59:54 root: 4 26592 -r-------- 1 root operator 90762969976 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:56 kernel: freeing inode /home/4 with 2112 blocks >>> Jun 21 15:59:56 root: starting snaptest 4 >>> Jun 21 15:59:56 kernel: free inode /home/4 had 2112 blocks >>> Jun 21 15:59:56 root: 4 26592 -r-------- 1 root operator 90762970240 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:57 root: starting snaptest 5 >>> Jun 21 15:59:57 root: 4 26592 -r-------- 1 root operator 90762970240 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:58 root: starting snaptest 6 >>> Jun 21 15:59:58 root: 4 26592 -r-------- 1 root operator 90762970216 >>> 21 Jun 15:59 /home/.snap/fscktest >>> Jun 21 15:59:59 kernel: freeing inode /home/4 with 192 blocks >>> Jun 21 15:59:59 root: starting snaptest 7 >>> Jun 21 15:59:59 kernel: free inode /home/4 had 192 blocks >>> Jun 21 15:59:59 root: 4 26592 -r-------- 1 root operator 90762970240 >>> 21 Jun 16:00 /home/.snap/fscktest >>> Jun 21 16:00:00 root: starting snaptest 8 >>> Jun 21 16:00:00 root: 4 26592 -r-------- 1 root operator 90762970240 >>> 21 Jun 16:00 /home/.snap/fscktest >>> >>> The "free inode /home/4 had NNN blocks" message during run of the mount >>> command is output of ffs_valloc(), because ffs_load_inode() has load the >>> disk inode 4 with a non zero i_blocks field. The corresponding "freeing >>> inode /home/4 with NNN blocks" message during the previous rm command >>> is output of my following diagnostic patch in function ffs_truncate(): >>> >>> --- ffs_inode.c.1st 2016-06-08 17:25:21.000000000 +0200 >>> +++ ffs_inode.c 2017-06-19 10:02:07.145360000 +0200 >>> @@ -551,6 +551,9 @@ >>> DIP_SET(ip, i_blocks, DIP(ip, i_blocks) - blocksreleased); >>> else /* sanity */ >>> DIP_SET(ip, i_blocks, 0); >>> + if (bootverbose == 2 && DIP(ip, i_blocks) > 0) >>> + printf("freeing inode %s/%lu with %ld blocks\n", >>> + fs->fs_fsmnt, (u_long)ip->i_number, >>> (long)DIP(ip, i_blocks)); >>> ip->i_flag |= IN_CHANGE; >>> #ifdef QUOTA >>> (void) chkdq(ip, -blocksreleased, NOCRED, 0); >>> >>> The rm command can only free all the blocks of the snapshotfile (means >>> i_blocks for inode 4 ends with zero) , if this file has the "correct" size: >>> >>> ls -ils /home/.snap/fscktest --> >>> 4 53184 -r-------- 1 root operator 90762970240 Jun 17 06:15 >>> /home/.snap/fscktest >>> >>> The size of the /home partition is given by >>> diskinfo /dev/mirror/gmsvt7p10.journal --> >>> /dev/mirror/gmsvt7p10.journal 512 90762954240 177271395 >>> >>> So we have 2769865 full 32kB blocks with size 90631864320. During >>> creating a snapshot a "last block" (32kB) is written at this offset >>> ending at 90762969088. Finally the snapblklist is written with >>> VOP_WRITE: "Write out the list of allocated blocks to the end of the >>> snapshot". In all my correct tests the table snapblklist is 1152 bytes >>> in size giving the correct size of the snapshot file : 90762970240. In >>> this case the table snapblklist has 144 entries of length 8: one lenght >>> entry and 143 logical block numbers recorded in mapacct_ufs2(): >>> >>> if (acctit && expungetype == BLK_SNAP && blkno != BLK_SNAP) >>> *ip->i_snapblklist++ = lblkno; >>> >>> The console output above shows three error situations with block >>> counters 704, 2112 and 192. Dividing these values by 8 gives exactly the >>> reduced size of the snapblocklist at the end of the snapshotfile, so in >>> these cases the snapshotfile is corrupt. >> I am not sure what do you mean by 'match' there. Could you explicitely >> mention what relations between snapshot size and leaked blocks of the >> free snapshot inode did you noted ? > > I too am confused here. Are you saying for example that 192 / 8 == 24 > and that the snapblocklist is short by 24 blocks? Because from the table > below, it appears to be short by only 3 blocks. In this example the snapblocklist is short by 24 bytes (= 3 table entries) and 24/8 = 3 calls to ffs_blkfree are missing. Ok, I give one more table to explain a little better: The meaning of the columns: #1 number of "free inode blocks" in kernel message #2 blocks from #1 divides by 8 (= fs_frag) #3 size of snapblklist write at the end of snapshotfile #4 ls -s of snapshotfile: 907629... #5 enties in table snapblklist, we have #5 = #3 / 8, because each entry in the table is of type ufs2_daddr_t #6 counter ct_blkfree, thats the number of calls to ffs_blkfree(). #7 missing table entries in snapblklist and calls of ffs_blkfree(). test #1 #2 #3 #4 #5 #6 #7 ----------------------------------------------- 1 ok 0 0 1152 ..70240 144 821 0 2 bad 704 88 1064 ..70152 133 810 11 3 bad 2112 264 888 ..69976 111 788 33 6 bad 192 24 1128 ..70216 141 818 3 The difference of #5 and #6 is the variable acctit which is set only for blkno != -1. In all my test (ok and bad) the function mapacct_ufs2() is called 680 times, the first calls look like this (diffblk = lastblk - oldblk): mapacct_ufs2:entry /home, inum=4, diffblkp=0xc, lblkno=0 mapacct_ufs2:entry /home, inum=4, diffblkp=0x3, lblkno=-1 mapacct_ufs2:entry /home, inum=4, diffblkp=0x1000, lblkno=12 mapacct_ufs2:entry /home, inum=4, diffblkp=0x2a4, lblkno=-1 mapacct_ufs2:entry /home, inum=4, diffblkp=0x1000, lblkno=4108 mapacct_ufs2:entry /home, inum=4, diffblkp=0x1000, lblkno=8204 mapacct_ufs2:entry /home, inum=4, diffblkp=0x1000, lblkno=12300 .... There are exact two calls with lblkno=-1 with together 0x2a7 -2 = 677 runs of the for loop where #5 is skipped. >>> I use a test kernel with some extra counters ct_* in mapacct_ufs2(): >>> >>> ++ct_blkno_all; >>> if (blkno == 0) >>> ++ct_blkno_0; >>> if (blkno == BLK_NOCOPY) >>> ++ct_blkno_nocopy; >>> if (blkno == BLK_SNAP) >>> ++ct_blkno_snap; >>> if (blkno == 0 || blkno == BLK_NOCOPY) >>> continue; >>> if (acctit && expungetype == BLK_SNAP && blkno != BLK_SNAP) { >>> *ip->i_snapblklist++ = lblkno; >>> ++ct_snapblklist; >>> } >>> if (blkno == BLK_SNAP) >>> blkno = blkstofrags(fs, lblkno); >>> ++ct_blkfree; >>> ffs_blkfree(ip->i_ump, fs, vp, blkno, fs->fs_bsize, inum, >>> vp->v_type, NULL); >>> >>> and for the 8 test runs shown above I can see these results using DTrace >>> at probe expunge_ufs2:return (blkno_snap is always 0): >>> >>> test blkno_all blkno_0 blkno_nocopy snapblklist blkfree cg_nocopy >>> ------------------------------------------------------------------- >>> 1 ok 2770545 353320 2416404 143 821 2416404 >>> 2 bad 2770545 587860 2181875 132 810 2416404 >>> 3 bad 2770545 956582 1813175 110 788 2416393 >>> 4 ok 2770545 353364 2416360 143 821 2416360 >>> 5 ok 2770545 353364 2416360 143 821 2416360 >>> 6 bad 2770545 418376 2351351 140 818 2416360 >>> 7 ok 2770545 353367 2416357 143 821 2416357 >>> 8 ok 2770545 353367 2416357 143 821 2416357 >>> >>> For correct tests the sum of blkno_0 and blkno_nocopy is always the same >>> (2769724), for bad tests especially the counter for blkno_nocopy is >>> significant lower. In the test table I give one more column cg_nocopy >>> for a counter I have added in cgaccount() to see how many entries are >>> set to BLK_NOCOPY during copy of cylinder group maps: >>> >>> if (ffs_isblock(fs, cg_blksfree(cgp), loc)) { >>> ++ct_cg_nocopy; >>> DIP_SET(ip, i_db[loc], BLK_NOCOPY); >>> } >>> ... >>> if (ffs_isblock(fs, cg_blksfree(cgp), loc)) { >>> ++ct_cg_nocopy; >>> ((ufs2_daddr_t *)(ibp->b_data))[indiroff] = >>> BLK_NOCOPY; >>> } >>> >>> For correct tests all the BLK_NOCOPY's which are set in cgaccount() can >>> later be seen in mapacct_ufs2(), for bad tests many of the BLK_NOCOPY's >>> have changed to 0. >>> >>> I looks like the rm command removing the previous snapshot in some way >>> runs "in the background" simultan to expunge_ufs2() and changes some of >>> the BLK_NOCOPY's to zero. So this may be a buffer management problem >>> which only exists on gjourneled partitions, maybe getblk/readblock used >>> in indiracct_ufs2() is not compatibel with gjournel in the special case >>> of creating or removing a spapshot. A hint in this direction is the >>> fact, that the first test after cleaning the partition with >>> umount /home; fsck -y /home; mount /home >>> always succeeds. The following modified test procedure never fails: >>> >>> for i in 1 2 3 4 5 6 7 8; do >>> echo "starting snaptest $i" >/dev/console >>> mount -u -o snapshot -o noatime -o async /home/.snap/fscktest /home >>> echo $(ls -ils /home/.snap/fscktest) >/dev/console >>> rm -f /home/.snap/fscktest /home >>> umount /home >>> mount /home >>> done >> After the allocations of required blocks for the snapshot inode >> are finished, the filesystem is suspended. You can see the >> call to vfs_write_suspend() in the ffs_snapshot() where the >> suspension is enforced. As part of the suspension, all soft-update >> workitems are flushed, this is done by vfs_write_suspend() calling >> VFS_SYNC(MNT_SUSPEND). >> >> UFS classifies writers into primary and secondary. Primary are mostly >> the writes initiated by the top-level syscall entries, like direct >> calls to write(2) or metadata-changing ops mkdir(), create() and so on. >> Secondary are writes performed when system initiates metadata updates >> during inactivation, quota updates, softdep background processing and >> similar. Primary modifications are blocked outright on suspension, while >> secondary are waited to finish in the mentioned VFS_SYNC(MNT_SUSPEND) >> call. >> >> If you can provide a proof that some SU-related activity happens after the >> suspension is established, this would be interesting to see. >> Might be it is something different and much simpler, but I do not see >> an obvious mistake in the code, after reading your observations. > > The mount information at the top shows: > > /dev/mirror/gmsvt7p10.journal on /home (ufs, asynchronous, local, noatime, gjournal) > > Thus no soft updates are being used. We are running on just a basic UFS > filesystem. So, soft update processing has no relevance here. > >>> Another proof that the snapshot file is corrupt when the snapblklist is >>> shortend is the fact that the rm command sporadically panics in a kernel >>> routine that is known to be correct: >>> >>> nread portion of the kernel message buffer: >>> dev = mirror/gmsvt7p10.journal, block = 19727560, fs = /home >>> panic: ffs_blkfree_cg: freeing free block >>> cpuid = 1 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>> 0xfffffe0857e3b1c0 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0857e3b270 >>> vpanic() at vpanic+0x126/frame 0xfffffe0857e3b2b0 >>> panic() at panic+0x43/frame 0xfffffe0857e3b310 >>> ffs_blkfree_cg() at ffs_blkfree_cg+0x5c6/frame 0xfffffe0857e3b3d0 >>> ffs_blkfree() at ffs_blkfree+0x99/frame 0xfffffe0857e3b430 >>> ffs_indirtrunc() at ffs_indirtrunc+0x474/frame 0xfffffe0857e3b510 >>> ffs_indirtrunc() at ffs_indirtrunc+0x423/frame 0xfffffe0857e3b5f0 >>> ffs_truncate() at ffs_truncate+0x10b4/frame 0xfffffe0857e3b7d0 >>> ufs_inactive() at ufs_inactive+0x16b/frame 0xfffffe0857e3b810 >>> VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 0xfffffe0857e3b840 >>> vinactive() at vinactive+0xc6/frame 0xfffffe0857e3b890 >>> vputx() at vputx+0x27a/frame 0xfffffe0857e3b8f0 >>> kern_unlinkat() at kern_unlinkat+0x243/frame 0xfffffe0857e3bae0 >>> amd64_syscall() at amd64_syscall+0x2c6/frame 0xfffffe0857e3bbf0 >>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0857e3bbf0 >>> --- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80095425a, rsp = >>> 0x7fffffffe988, rbp = 0x7fffffffea20 --- >>> >>> Any hints solving this problem are welcome. > > Per the suggestion at the top, I recommend trying your test without > gjournal present to see if the bug goes away. If that is true, then > we can focus our attention on a possible race during rm in the gjournal > code. > > Kirk McKusick I have done as explained above. Some more hints may help for debugging this. 1. Output of dumpfs of the partition is magic 19540119 (UFS2) time Sun Jun 25 03:46:09 2017 superblock location 65536 id [ 561bcaa3 624b156b ] ncg 139 size 22158924 blocks 21459451 bsize 32768 shift 15 mask 0xffff8000 fsize 4096 shift 12 mask 0xfffff000 frag 8 shift 3 fsbtodb 3 minfree 8% optim time symlinklen 120 maxbsize 32768 maxbpg 4096 maxcontig 4 contigsumsize 4 nbfree 2413023 ndir 229 nifree 11153267 nffree 274 bpg 20035 fpg 160280 ipg 80256 unrefs 0 nindir 4096 inopb 128 maxfilesize 2252349704110079 sbsize 4096 cgsize 32768 csaddr 5056 cssize 4096 sblkno 24 cblkno 32 iblkno 40 dblkno 5056 cgrotor 123 fmod 0 ronly 0 clean 0 metaspace 6408 avgfpdir 64 avgfilesize 16384 flags gjournal fsmnt /home volname swuid 0 providersize 22158924 2. I am quite sure that the process g_journal_switcher does not break things during run of "mount -o snapshot". I have severel DTrace output of the problem, where g_journal_switcher sleeps all the time. 3. The probe expunge_ufs2:return is the first probe from several DTrace probing that shows a difference between good and bad. 4. The problem occurs for many years on several production server and partitions where only one snapshot is taken every day, but not all and not very often. On newer server the "free inode" messages increases. On my test server I have a "freezed" partition /home that shows the problem with less than ten runs all the time. If I run DTrace with a lot of probes then the problem sometimes becomes a "Heisenbug". Andreas Longwitz From owner-freebsd-fs@freebsd.org Sun Jun 25 15:23:06 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B193CD93CFC for ; Sun, 25 Jun 2017 15:23:06 +0000 (UTC) (envelope-from dchagin@mordor.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 881A073796 for ; Sun, 25 Jun 2017 15:23:05 +0000 (UTC) (envelope-from dchagin@mordor.heemeyer.club) Received: from mordor.heemeyer.club (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id v5PFMvu5048697 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 25 Jun 2017 15:22:59 GMT (envelope-from dchagin@mordor.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be mordor.heemeyer.club Received: from mordor.heemeyer.club (localhost [127.0.0.1]) by mordor.heemeyer.club (8.15.2/8.15.1) with ESMTPS id v5PFMvXV021951 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 25 Jun 2017 18:22:57 +0300 (MSK) (envelope-from dchagin@mordor.heemeyer.club) Received: (from dchagin@localhost) by mordor.heemeyer.club (8.15.2/8.15.2/Submit) id v5PFMuL4021950; Sun, 25 Jun 2017 18:22:56 +0300 (MSK) (envelope-from dchagin) Date: Sun, 25 Jun 2017 18:22:56 +0300 From: Chagin Dmitry To: Willem Jan Withagen Cc: FreeBSD Filesystems Subject: Re: Strangely truncated names in linprocfs in jail Message-ID: <20170625152256.GA21941@mordor.heemeyer.club> References: <39fc567b-a9d6-ea7d-31a9-51d87f0cb803@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39fc567b-a9d6-ea7d-31a9-51d87f0cb803@digiware.nl> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 15:23:06 -0000 On Wed, Jun 14, 2017 at 04:13:36PM +0200, Willem Jan Withagen wrote: > Hi, > > I have mount linprocfs in a jail on /compat/linux/proc > And that seems to work. > > Other than that I have strangely truncated names there: > > root@ceph-0:/compat/linux/proc # ls > 81117 81218 devices meminfo net > self sys > 81185 cmdline filesyst? mounts > partitio? stat uptime > 81216 cpuinfo loadavg mtab scsi > swaps version > > Both filesystems and partitions seem to malformed. > > And even stranger, in the linprocfs mount on the actual host (not > jailed) those 2 files do not show. > fixed by r320329 -- From owner-freebsd-fs@freebsd.org Sun Jun 25 15:53:40 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03C42D945F9 for ; Sun, 25 Jun 2017 15:53:40 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9F874457 for ; Sun, 25 Jun 2017 15:53:39 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt0-x233.google.com with SMTP id 32so10420308qtv.1 for ; Sun, 25 Jun 2017 08:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:date:subject:message-id :to; bh=zqIuUOpkrtdxfeSNCTR6UoSmyoXUXQZcWYsASxpBras=; b=1B++5fuqpJwle8ihFEU+dtHjlNM+0NceaRR1fp+vra+KWAvyCR9eSajLuS5/oiBXce d/Af6Kcsxql1rUGfbK5rQpHAx/ujVktiLdAV06/yi2W6FBIwUvApua45P5bctEo0Lk+D PcNZSpdO7jAirtP/2Jykcs/EQheVgUieqWaFiL+83f1eZqaRZFwpikedg5+zXshSfmPR HdOU0hHE2SwDNxZd1U3E3Ru+hEEN6pB2p24lohP+NoUOpcAj4eKH0jkV3l/ALI4bbAqs 0XnPIuZ6DDQHw+FdJRVv7hZwSXVIjHNsVJb0WF3z3md5pp6iASQDCMCxWrAezgWjNlKL EIvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:to; bh=zqIuUOpkrtdxfeSNCTR6UoSmyoXUXQZcWYsASxpBras=; b=UMlGw1n+02pcFyK0B7Moo8NKIHqjNlxitAMvY5hSA+14iVk6cRrAXKyXSzryXUWJRa SFRE36T6DdNadv3twOthiXAHOi6Xci/OAcBSZgfllyw1EgjXbCwx4LGoULnXN7CyO2PW 5EIJC+hOAZYRbDC84gFsJl2HyuYW5uqOtr82hN27kj7iipMwjoviIAMSn1EMdEUhknlZ /GVwk6DjbH9KBHpSub03f8oM8I8+B9ORC9OeUVlzV5mk/8CRv1EPlNKgerq3zI0UEfEQ 089O5Y3g4veE1NfQb7QrBdO7eeyRArmYcqXEULl73cDBeRtt8K1J0OGDbSwggFijtrxM +tmQ== X-Gm-Message-State: AKS2vOzumHkX/nB3uc6abMdf5J6X9u75UldvewHBNUrzxiqLzpG9u/Tz 65YzZKlyhac4Z6hEb/OGsQ== X-Received: by 10.237.49.133 with SMTP id 5mr2716772qth.53.1498406018019; Sun, 25 Jun 2017 08:53:38 -0700 (PDT) Received: from [25.229.139.215] (ool-d18c2957.dyn.optonline.net. [209.140.41.87]) by smtp.gmail.com with ESMTPSA id t35sm7885096qte.38.2017.06.25.08.53.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jun 2017 08:53:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Mark Saad Mime-Version: 1.0 (1.0) Date: Sun, 25 Jun 2017 11:43:48 -0400 Subject: Self encrypting drives Message-Id: <4F634DDE-9B7E-4246-85FD-F481418500B1@longcount.org> To: freebsd-fs@freebsd.org X-Mailer: iPhone Mail (14F89) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 15:53:40 -0000 Hi everyone, I ran into a very strange issue last week . I had a server with a basic zf= s setup , running 11-Release-p11 amd64 . 4 disks in pool of two mirrors . I= also had a 400g disk I was using in a 60/40 split with gpt partitions ,for l= 2arc and slog . All was good until a reboot where the ssd out of the blue de= cided it was encrypted. On that reboot the box was waiting at a enter passwo= rd prompt . I had never set this up and had no idea what it was . The disk i= s an ocz p5: tg32c10480gk . Also the ssd going bananas caused my pool to bre= ak in interesting ways . More on that later . So I have Two questions. Is there a way from inside FreeBSD to enable / disable sed or fed on a disk t= hat supports it ? In Linux hdparm can do this . Second question has anyone e= ver seen a disk do this ? Could this be a sign it was failed?=20 So zpool fun ; so the ssd was inaccessible after the kernel loaded . The is c= ould see the disk but most of the commands sent to it failed . The odd issue= was the zpool would not properly mount any zfs file systems and panic the b= ox . I suspect this is from my stupidity of putting slog and l2arc on one di= sk . Anyone have any ideas on this ?=20 --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-fs@freebsd.org Sun Jun 25 20:22:45 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86449D9950E for ; Sun, 25 Jun 2017 20:22:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464487CB2E; Sun, 25 Jun 2017 20:22:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id F135543C5B; Sun, 25 Jun 2017 22:22:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_bNGpfHDaEe; Sun, 25 Jun 2017 22:22:32 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 3B02843C5A; Sun, 25 Jun 2017 22:22:32 +0200 (CEST) Subject: Re: Strangely truncated names in linprocfs in jail To: Chagin Dmitry Cc: FreeBSD Filesystems References: <39fc567b-a9d6-ea7d-31a9-51d87f0cb803@digiware.nl> <20170625152256.GA21941@mordor.heemeyer.club> From: Willem Jan Withagen Message-ID: Date: Sun, 25 Jun 2017 22:22:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170625152256.GA21941@mordor.heemeyer.club> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 20:22:45 -0000 On 25-6-2017 17:22, Chagin Dmitry wrote: > On Wed, Jun 14, 2017 at 04:13:36PM +0200, Willem Jan Withagen wrote: >> Hi, >> >> I have mount linprocfs in a jail on /compat/linux/proc >> And that seems to work. >> >> Other than that I have strangely truncated names there: >> >> root@ceph-0:/compat/linux/proc # ls >> 81117 81218 devices meminfo net >> self sys >> 81185 cmdline filesyst? mounts >> partitio? stat uptime >> 81216 cpuinfo loadavg mtab scsi >> swaps version >> >> Both filesystems and partitions seem to malformed. >> >> And even stranger, in the linprocfs mount on the actual host (not >> jailed) those 2 files do not show. >> > fixed by r320329 > Right, Thanx, I'll have to find some time to upgrade. --WjW From owner-freebsd-fs@freebsd.org Sun Jun 25 21:00:27 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C687AD99F7C for ; Sun, 25 Jun 2017 21:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB0B57D8CE for ; Sun, 25 Jun 2017 21:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5PL01h1013591 for ; Sun, 25 Jun 2017 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201706252100.v5PL01h1013591@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 25 Jun 2017 21:00:27 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 21:00:27 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic New | 217062 | for file systems mounted with -o noexec, exec=off Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Jun 26 09:29:02 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BBB2DA587A for ; Mon, 26 Jun 2017 09:29:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A0AF70DB7 for ; Mon, 26 Jun 2017 09:29:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5Q9T1Tt067888 for ; Mon, 26 Jun 2017 09:29:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 210316] panic after trying to r/w mount msdosfs on write protected media Date: Mon, 26 Jun 2017 09:29:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 09:29:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210316 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imp@FreeBSD.org, | |kib@FreeBSD.org --- Comment #3 from Andriy Gapon --- Another panic of a similar nature: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 1; apic id =3D 01 instruction pointer =3D 0x20:0xffffffff80633e06 stack pointer =3D 0x28:0xfffffe07169c6240 frame pointer =3D 0x28:0xfffffe07169c6290 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 14163 (gvfs-hal-volume-mon) trap number =3D 9 panic: general protection fault cpuid =3D 1 time =3D 1498465614 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80439f4b =3D db_trace_self_wrapper+0x2b/frame 0xfffffe07169c5df0 kdb_backtrace() at 0xffffffff8068b369 =3D kdb_backtrace+0x39/frame 0xfffffe07169c5ea0 vpanic() at 0xffffffff806521f2 =3D vpanic+0x162/frame 0xfffffe07169c5ee0 panic() at 0xffffffff80651f23 =3D panic+0x43/frame 0xfffffe07169c5f40 trap_fatal() at 0xffffffff8085a170 =3D trap_fatal+0x310/frame 0xfffffe07169= c5f90 trap() at 0xffffffff80859717 =3D trap+0x97/frame 0xfffffe07169c6150 trap_check() at 0xffffffff8085a49a =3D trap_check+0x2a/frame 0xfffffe07169c= 6170 calltrap() at 0xffffffff80842b1a =3D calltrap+0x8/frame 0xfffffe07169c6170 --- trap 0x9, rip =3D 0xffffffff80633e06, rsp =3D 0xfffffe07169c6240, rbp = =3D 0xfffffe07169c6290 --- __mtx_lock_flags() at 0xffffffff80633e06 =3D __mtx_lock_flags+0x46/frame 0xfffffe07169c6290 g_vfs_strategy() at 0xffffffff805cc586 =3D g_vfs_strategy+0x36/frame 0xfffffe07169c62c0 bstrategy() at 0xffffffff806e4326 =3D bstrategy+0x26/frame 0xfffffe07169c62= d0 bufwrite() at 0xffffffff806e258f =3D bufwrite+0x1df/frame 0xfffffe07169c6310 bwrite() at 0xffffffff806e51d6 =3D bwrite+0x26/frame 0xfffffe07169c6320 bawrite() at 0xffffffff806e4cbd =3D bawrite+0xd/frame 0xfffffe07169c6330 vop_stdfsync() at 0xffffffff806f11b0 =3D vop_stdfsync+0x1b0/frame 0xfffffe07169c6380 VOP_FSYNC_APV() at 0xffffffff808a4fea =3D VOP_FSYNC_APV+0xfa/frame 0xfffffe07169c63b0 VOP_FSYNC() at 0xffffffff806e49f8 =3D VOP_FSYNC+0x28/frame 0xfffffe07169c63= e0 bufsync() at 0xffffffff806e2687 =3D bufsync+0x27/frame 0xfffffe07169c6400 bufobj_invalbuf() at 0xffffffff806fe937 =3D bufobj_invalbuf+0x287/frame 0xfffffe07169c6460 vinvalbuf() at 0xffffffff806fec1a =3D vinvalbuf+0x8a/frame 0xfffffe07169c64= 90 vgonel() at 0xffffffff80701fbe =3D vgonel+0x16e/frame 0xfffffe07169c64d0 vgone() at 0xffffffff8070236f =3D vgone+0x2f/frame 0xfffffe07169c64f0 devfs_delete() at 0xffffffff805425ae =3D devfs_delete+0x15e/frame 0xfffffe07169c6550 devfs_populate_loop() at 0xffffffff80542d4f =3D devfs_populate_loop+0x3cf/f= rame 0xfffffe07169c65a0 devfs_populate() at 0xffffffff8054296a =3D devfs_populate+0x4a/frame 0xfffffe07169c65c0 devfs_populate_vp() at 0xffffffff80546a6e =3D devfs_populate_vp+0x5e/frame 0xfffffe07169c65f0 devfs_lookup() at 0xffffffff80545636 =3D devfs_lookup+0x16/frame 0xfffffe07169c6620 VOP_LOOKUP_APV() at 0xffffffff808a2d93 =3D VOP_LOOKUP_APV+0xf3/frame 0xfffffe07169c6650 VOP_LOOKUP() at 0xffffffff806f5e29 =3D VOP_LOOKUP+0x29/frame 0xfffffe07169c= 6680 lookup() at 0xffffffff806f52b8 =3D lookup+0x3e8/frame 0xfffffe07169c6700 namei() at 0xffffffff806f4b5d =3D namei+0x3ad/frame 0xfffffe07169c67a0 kern_statat() at 0xffffffff8070b3fb =3D kern_statat+0x9b/frame 0xfffffe0716= 9c69b0 sys_fstatat() at 0xffffffff8070b7af =3D sys_fstatat+0x2f/frame 0xfffffe0716= 9c6ab0 syscallenter() at 0xffffffff8085aaf6 =3D syscallenter+0x316/frame 0xfffffe07169c6b00 amd64_syscall() at 0xffffffff8085a69f =3D amd64_syscall+0x1f/frame 0xfffffe07169c6bf0 Xfast_syscall() at 0xffffffff80842dfb =3D Xfast_syscall+0xfb/frame 0xfffffe07169c6bf0 --- syscall (552, FreeBSD ELF64, sys_fstatat), rip =3D 0x80234f65a, rsp =3D 0x7fffffffd798, rbp =3D 0x7fffffffd8e0 --- Uptime: 3d14h59m16s --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jun 26 14:36:58 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51198D88D90; Mon, 26 Jun 2017 14:36:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0191F7BAFF; Mon, 26 Jun 2017 14:36:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ua0-x22d.google.com with SMTP id 70so2052976uau.0; Mon, 26 Jun 2017 07:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eLJC3DaMFhxev2U7RyM84p6FOR/QOX+FGgwQi+EeruU=; b=KIw+jUmHLosjac+4f1585lcBf/vh2n4jd/cx53THr0r9fvbpVlcg7qT2m+jn7+g/LQ xs2xdT4W9V0gppJ1IibMP3PZF/XLsqGTqwmWcaAtKia4lVZwwCoJQHRN4Y3rbzTfYcH4 t+0unczepOnoysXrvPDhaokUd1UwcS/UQvN9cdMNF7EQC3tWLMUSOSFlMcrnCCaUva55 WRHWEE4bu43kaPbEfbloyfQoblxwcFvmcDEutdEn1lg9whX1fWLVx0LDBSqwcm3Nhy14 0NQOhCs3iL/bf8OJEpLDWcjLNNTNGdQnPJi3UEzYB6ZcIG3zh6WnfY4yESJ9wX3/XVcI NvxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=eLJC3DaMFhxev2U7RyM84p6FOR/QOX+FGgwQi+EeruU=; b=sgaQTH8xPHtOpHPTichr92U/r/PDrtkDUSXYMwr4xxTCTMofW0DXwscmIOeJD82Tou eA/oTaNe9HHdOhgoQNz21GE5iKM/7cj+ouCgiK1cG9CYgLQU/pV3au2yCapTdgR7htpC FJRqJa9yUGUpZ7FFTFMg3RHAlVKzyDW6ocGCG2TxAiNt5C2rTuYyjFHIry6dJ4UeznMo LaHziBxJsSY+8yRtV4sX3CQE6YTqEG0zAYeX5g1+/8q+wS8LKw2VZYRJgCmJPOs3oCr8 ZPt98l4MV+QxkGgYYOfWMCH7q7+vdCwWErdv7JT2wey9mqBcaXA4WB2pwh0bs4ryIFkz Z/rg== X-Gm-Message-State: AKS2vOxjH++hfxctLZ0UHccv5kfKVoPPdfWrZ48jw2iv9tIrV0p0qu5C ixrg0kYNIsN37rtK7GXXO/cISAMfL1Vw X-Received: by 10.176.77.155 with SMTP id s27mr246693uag.75.1498487816823; Mon, 26 Jun 2017 07:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.239 with HTTP; Mon, 26 Jun 2017 07:36:56 -0700 (PDT) Reply-To: araujo@freebsd.org In-Reply-To: References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> From: Marcelo Araujo Date: Mon, 26 Jun 2017 22:36:56 +0800 Message-ID: Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: Guido Falsi Cc: Warner Losh , FreeBSD FS , Glen Barber , FreeBSD-STABLE Mailing List , Jonathan Chen , Peter Blok Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:36:58 -0000 2017-06-23 4:02 GMT+08:00 Guido Falsi : > On 06/22/17 19:06, Guido Falsi wrote: > >> On 06/22/17 18:38, Warner Losh wrote: >> > > I'll followup as soon as I have easier use case to reproduce it. I first >> need to revert to an image affected by the problem. >> > > I have made a few more tests. > > I am able to trigger this bug easily by running gpart. > > I'm testing on a PCEngines APU2 board with SD memory card. > > # gpart set -a active -i 1 mmcsd0 > active set on mmcsd0s1 > # fsck_ffs -n /dev/mmcsd0s1a > ** /dev/mmcsd0s1a (NO WRITE) > ** Last Mounted on /mnt > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > Segmentation fault > # shutdown -r now > /sbin/shutdown: Device not configured > > also, if I open another shell I can't perform many other operations which > are not failing in the previous root shell: > > > tail /var/log/messages > /usr/bin/tail: Device not configured. > > > BTW while testing this multiple times I also had the root shell segfault > while browsing history, so it should be quite easy to reproduce on your > side too. running the gpart set command triggers it every time, with > slightly different bu always disruptive symptoms. > > There is a chance it only shows with these embedded systems storage > controllers though. > > -- > Guido Falsi > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Hi, Could you guys test this patch: https://reviews.freebsd.org/D11365? Would it solve the issue? Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-fs@freebsd.org Mon Jun 26 17:29:48 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C88C0D8CB06 for ; Mon, 26 Jun 2017 17:29:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6169812A8 for ; Mon, 26 Jun 2017 17:29:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5QHTmhW058691 for ; Mon, 26 Jun 2017 17:29:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220163] Allowed characters in UFS volume labels using /sbin/newfs Date: Mon, 26 Jun 2017 17:29:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:29:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220163 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: mckusick Date: Mon Jun 26 17:29:32 UTC 2017 New revision: 320365 URL: https://svnweb.freebsd.org/changeset/base/320365 Log: MFC of 320176: Allow '_' in labels when specifying -L to newfs. PR: 220163 Reported by: Keve Nagy Reviewed by: kib Approved by: re@ (Xin Li) Changes: _U stable/11/ stable/11/sbin/newfs/newfs.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jun 26 17:33:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F824D8CD90 for ; Mon, 26 Jun 2017 17:33:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E1A68176C for ; Mon, 26 Jun 2017 17:33:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5QHXrms076070 for ; Mon, 26 Jun 2017 17:33:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220163] Allowed characters in UFS volume labels using /sbin/newfs Date: Mon, 26 Jun 2017 17:33:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:33:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220163 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: mckusick Date: Mon Jun 26 17:33:33 UTC 2017 New revision: 320366 URL: https://svnweb.freebsd.org/changeset/base/320366 Log: MFC of 320176: Allow '_' in labels when specifying -L to newfs. PR: 220163 Reported by: Keve Nagy Reviewed by: kib Changes: _U stable/10/ stable/10/sbin/newfs/newfs.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jun 26 17:55:02 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A387CD8D35F for ; Mon, 26 Jun 2017 17:55:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 876C18203B for ; Mon, 26 Jun 2017 17:55:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5QHt2rE020842 for ; Mon, 26 Jun 2017 17:55:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220163] Allowed characters in UFS volume labels using /sbin/newfs Date: Mon, 26 Jun 2017 17:55:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mckusick@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:55:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220163 Kirk McKusick changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #8 from Kirk McKusick --- This fix has now been MFC'ed to 10 and 11 and should appear in 11.1. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Mon Jun 26 18:11:31 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B352D8D83E; Mon, 26 Jun 2017 18:11:31 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from smtpq6.tb.mail.iss.as9143.net (smtpq6.tb.mail.iss.as9143.net [212.54.42.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF311826D6; Mon, 26 Jun 2017 18:11:30 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from [212.54.42.134] (helo=smtp10.tb.mail.iss.as9143.net) by smtpq6.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dPYTp-000621-EP; Mon, 26 Jun 2017 20:11:21 +0200 Received: from 5ed15678.cm-7-2b.dynamic.ziggo.nl ([94.209.86.120] helo=wan0.bsd4all.org) by smtp10.tb.mail.iss.as9143.net with esmtp (Exim 4.86_2) (envelope-from ) id 1dPYTp-0001hU-Ab; Mon, 26 Jun 2017 20:11:21 +0200 Received: from newnas (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id A364D21B; Mon, 26 Jun 2017 20:11:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1S9-VQDCGRA; Mon, 26 Jun 2017 20:11:18 +0200 (CEST) Received: from [192.168.1.64] (mm [192.168.1.64]) by wan0.bsd4all.org (Postfix) with ESMTPSA id 81F0F211; Mon, 26 Jun 2017 20:11:18 +0200 (CEST) From: Peter Blok Message-Id: <2D4D4BE2-1D05-43EF-8964-6478EE612175@bsd4all.org> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) Date: Mon, 26 Jun 2017 20:11:17 +0200 In-Reply-To: Cc: Guido Falsi , Warner Losh , FreeBSD FS , Glen Barber , FreeBSD-STABLE Mailing List , Jonathan Chen To: araujo@freebsd.org References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-SourceIP: 94.209.86.120 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.2 cv=S5Wp+MkP c=1 sm=1 tr=0 a=IkzOOneQUJP1+bAPekPvBg==:17 a=LWSFodeU3zMA:10 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=j90g3uC65GxMD2nljHgA:9 a=QEXdDO2ut3YA:10 a=vUPWEWiMAAAA:8 a=ERGEnrLWe0TpccyqpOEA:9 a=H4FIEKXvFUr3Javy:21 a=_W_S_7VecoQA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=IjZwj45LgO3ly-622nXo:22 a=s3Yi14Of9AgBIP63TAoC:22 none X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 18:11:31 -0000 Marcelo, This fix solved the problem for RPI-1B. I=E2=80=99ll do some more = testing on other RPI and nanobsd variants. Peter > On 26 Jun 2017, at 16:36, Marcelo Araujo = wrote: >=20 >=20 >=20 > 2017-06-23 4:02 GMT+08:00 Guido Falsi >: > On 06/22/17 19:06, Guido Falsi wrote: > On 06/22/17 18:38, Warner Losh wrote: >=20 > I'll followup as soon as I have easier use case to reproduce it. I = first need to revert to an image affected by the problem. >=20 > I have made a few more tests. >=20 > I am able to trigger this bug easily by running gpart. >=20 > I'm testing on a PCEngines APU2 board with SD memory card. >=20 > # gpart set -a active -i 1 mmcsd0 > active set on mmcsd0s1 > # fsck_ffs -n /dev/mmcsd0s1a > ** /dev/mmcsd0s1a (NO WRITE) > ** Last Mounted on /mnt > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > Segmentation fault > # shutdown -r now > /sbin/shutdown: Device not configured >=20 > also, if I open another shell I can't perform many other operations = which are not failing in the previous root shell: >=20 > > tail /var/log/messages > /usr/bin/tail: Device not configured. >=20 >=20 > BTW while testing this multiple times I also had the root shell = segfault while browsing history, so it should be quite easy to reproduce = on your side too. running the gpart set command triggers it every time, = with slightly different bu always disruptive symptoms. >=20 > There is a chance it only shows with these embedded systems storage = controllers though. >=20 > --=20 > Guido Falsi > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs = > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org = " >=20 >=20 > Hi, >=20 > Could you guys test this patch: https://reviews.freebsd.org/D11365 = ? > Would it solve the issue? >=20 > Best, > --=20 >=20 > --=20 > Marcelo Araujo (__) > araujo@FreeBSD.org \\\'',) > http://www.FreeBSD.org \/ \ ^ > Power To Server. .\. /_) From owner-freebsd-fs@freebsd.org Mon Jun 26 20:18:46 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 061AED90AE0; Mon, 26 Jun 2017 20:18:46 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B824C64168; Mon, 26 Jun 2017 20:18:45 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3wxL3l3PYPzb57; Mon, 26 Jun 2017 22:18:43 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id vhSOYniRzazE; Mon, 26 Jun 2017 22:18:41 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Mon, 26 Jun 2017 22:18:41 +0200 (CEST) Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: araujo@freebsd.org Cc: FreeBSD-STABLE Mailing List , FreeBSD FS , Glen Barber , Jonathan Chen , Peter Blok References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> From: Guido Falsi Message-ID: <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> Date: Mon, 26 Jun 2017 22:18:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:18:46 -0000 On 06/26/17 16:36, Marcelo Araujo wrote: > Hi, > > Could you guys test this patch: https://reviews.freebsd.org/D11365? > Would it solve the issue? > Hi, I confirm the patch fixes the problem for me. Thanks! -- Guido Falsi From owner-freebsd-fs@freebsd.org Tue Jun 27 01:26:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 432EAD973E0; Tue, 27 Jun 2017 01:26:13 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E77627291F; Tue, 27 Jun 2017 01:26:12 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by mail-ua0-x230.google.com with SMTP id g40so10518808uaa.3; Mon, 26 Jun 2017 18:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hdd2Gh1nrQBvvgjCGK3WmfWoOEJCRE9ZcLLER2Wgx78=; b=DR/LlAuubqnRWe0eZfD6cZCgB8ejjWhUeb7gs7Yw/1YgrSbwlkBTSvSlT/AGTraMHu nlql/u2REANLYBpyAT/DikXvgSOnI9uiVl370BteauAYmryUcFHo42Y+FAwdsEWSOX3Q DCh/pczaZoxCPvLU9EZ57xqZLqrdqleCmNEnf1hjEdInGrAqBFOoR+e3v34l5pknnAWd OSsoJeynBLEGOflYABNxDnQXu0zRaAtW59hbCd2ikiwufl+IuiLbuX1QZ3KQ1nrFJ3Uk wiztEHaV5FLADCRD03Y/HPA23zQG1kNS8IWn5wDLn5umA5Mt2jBpxNicwRtWoHMYE3VZ BanQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=hdd2Gh1nrQBvvgjCGK3WmfWoOEJCRE9ZcLLER2Wgx78=; b=CfEcuFUxt2z3vrGfko8Y1WQPoFmb8cEbW7Zxby3XQAfAxm87c80DWCmhK0hGxB4BBC 6p8w57Lhp7/dCJI1bJgT4IB8KPxD9RRlR50kDwrygjZht3fj20ItIZ+Wa18dAHfnCCT7 6Yz2/fL6NKzREkKuZ9bBs9/cI1drRNJ9iC05dKLWz90GIaXYZ1Q4LbRkzfnVG+pLleqo OGeOFTXP+QwKv653WgqL1au3w4sYbOdeJm8k3N/AJp1kk2mnidjZvT5JAGAuDzv+4lbn Egmb1vNOlwnb95Xyp4aJP9YhsJ2AdjZOvy9b6w2RbeJgCLx4q0fP4viIxgRjMPfJvaGm 8Myg== X-Gm-Message-State: AKS2vOzKjTCs05E5bFGPIymvcx4bLS/2pqnCcZizQqKayBhMzGxym6Mr lWC88qiCVhugKTbFGgpRw2KJ58LW9pxR X-Received: by 10.176.77.155 with SMTP id s27mr1448542uag.75.1498526771505; Mon, 26 Jun 2017 18:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.16.239 with HTTP; Mon, 26 Jun 2017 18:26:11 -0700 (PDT) Reply-To: araujo@freebsd.org In-Reply-To: <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> References: <20170610123435.GB69235@FreeBSD.org> <10A08FC1-C84E-4D06-9360-B7C3848F4680@bsd4all.org> <05e6bd02-3582-aea1-5fc3-19caa4073f94@FreeBSD.org> <0c4c58d6-f34c-a358-3bda-122913110c6d@FreeBSD.org> <5a869fee-c79c-cfd8-6b02-f1b8b2507c2a@FreeBSD.org> From: Marcelo Araujo Date: Tue, 27 Jun 2017 09:26:11 +0800 Message-ID: Subject: Re: vnode_pager_generic_getpages_done: I/O read error 5 caused by r318394 (was Re: FreeBSD 11.1-BETA1 Now Available) To: Guido Falsi Cc: FreeBSD-STABLE Mailing List , FreeBSD FS , Glen Barber , Jonathan Chen , Peter Blok Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 01:26:13 -0000 2017-06-27 4:18 GMT+08:00 Guido Falsi : > On 06/26/17 16:36, Marcelo Araujo wrote: > > Hi, >> >> Could you guys test this patch: https://reviews.freebsd.org/D11365? >> Would it solve the issue? >> >> > Hi, > > I confirm the patch fixes the problem for me. > > Thanks! > > -- > Guido Falsi > Thanks all for the test, very appreciated! I just committed it: r320390 with MFC for 3 days. Also thanks trasz@ to point me out to this thread that I was not aware of. Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-fs@freebsd.org Tue Jun 27 17:43:49 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73F4FD8C257 for ; Tue, 27 Jun 2017 17:43:49 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4135776529 for ; Tue, 27 Jun 2017 17:43:49 +0000 (UTC) (envelope-from gcorcoran@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=F/IVTepN c=1 sm=1 tr=0 a=jCH78jcaBILaJ1B6H+di6A==:117 a=jCH78jcaBILaJ1B6H+di6A==:17 a=IkcTkHD0fZMA:10 a=C4n8AZmYZaTIiblOuQMA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: Z2NvcmNvcmFuQHJjbi5jb20= Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=gcorcoran@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=gcorcoran@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=gcorcoran; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 64.121.14.202 is neither permitted nor denied by domain of rcn.com) Received: from [64.121.14.202] ([64.121.14.202:60607] helo=[10.56.78.168]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPA id B8/DA-26624-E4992595; Tue, 27 Jun 2017 13:43:42 -0400 To: freebsd-fs@freebsd.org From: Gary Corcoran Subject: Encrypted ZFS boot failure on 11.* Message-ID: <5d0d9bc9-b74a-af78-aef8-786607c68e3b@rcn.com> Date: Tue, 27 Jun 2017 13:35:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 17:43:49 -0000 The below all refer to AMD64 versions. I wanted to create a backup server from a few years old machine, so I bought five drives to create a ZFS raidz1. And naturally wanted to put the latest non-experimental version of FreeBSD on it, 11.*. And I wanted the drives to be encrypted. But every version of FreeBSD 11 I tried, including the latest 11.1-BETA1, has the same bug. Using the "guided Auto ZFS" option in the installer, I chose raidz1, GPT (BIOS) partioning, and encryption on. Installations would proceed without any problem. But then, upon rebooting into the newly installed system, I would get the following error messages (after entering the GELI passphrase): error 1 lba 90728 failed to clear pad 2 area of primary vdev failed to read pad 2 area of primary vdev ZFS: i/o error - all block copies unavailable I was worried that I might have gotten a bad disk drive. But apparently no. For when I did the exact same installation, except no encryption, there were no errors and it successfully booted. From a little bit of googling I understand that the pad2 area has to do with a one-time "nextboot" ZFS feature, and thus the area is cleared after booting. I presume that is true whether or not the disks are encrypted, so having a successful boot without encryption should mean that the pad2 area of the disk(s) was accessed without a problem, as long as those sectors aren't encrypted. Next I tried installing FreeBSD 10.3-Release. Doing the same type of installation, with encryption ON, the system installed and booted without any problems. So in summary, encrypted ZFS works in version 10.3, but is broken in all 11.* versions. I am very surprised that no one else has run into this major problem. I've done so many installs that I am tired of doing them, and since the 10.3 install works, I'm just going to use that. But I thought that, especially since you're in BETA, this should be reported. Gary Retired Software Engineer FreeBSD user since 2.2 From owner-freebsd-fs@freebsd.org Wed Jun 28 18:21:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43C67DA758B for ; Wed, 28 Jun 2017 18:21:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 318EF82900 for ; Wed, 28 Jun 2017 18:21:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5SILC9b077483 for ; Wed, 28 Jun 2017 18:21:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 215519] [fusefs] strange issue when glusterfs is fuse mounted, files not handled as expected. Date: Wed, 28 Jun 2017 18:21:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: flo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 18:21:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215519 Florian Smeets changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |flo@FreeBSD.org --- Comment #1 from Florian Smeets --- This was fixed by r320451 in head. Tested with gluster 3.11.0. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Wed Jun 28 23:00:45 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 361CFD86338 for ; Wed, 28 Jun 2017 23:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24537655A8 for ; Wed, 28 Jun 2017 23:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5SN0j6G075817 for ; Wed, 28 Jun 2017 23:00:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 215519] [fusefs] strange issue when glusterfs is fuse mounted, files not handled as expected. Date: Wed, 28 Jun 2017 23:00:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: craig001@lerwick.hopto.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 23:00:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215519 --- Comment #2 from craig001@lerwick.hopto.org --- Thanks Florian, I'll check it out and get the port updated over the next w= eek. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jun 29 11:49:05 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E4B3D9B030; Thu, 29 Jun 2017 11:49:05 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF8178152D; Thu, 29 Jun 2017 11:49:04 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id w126so79655522wme.0; Thu, 29 Jun 2017 04:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=/0PeDsqUvWY8Rmc0HQnOBmBLDJcNSSBrJMtjHVZ6l44=; b=MqL772KK6OUCZ5UIA3Zd8ub2P189RwetjkCP4Eq+B6NwMecz8Pu521g6UqLfItQad/ N5TqNeBmcSGzOrhe3qSDZKGJv3x3zGO1WLWdSSLRbZN07bIdG0FgU3Gf0OuHt0Tffj+h QNc2UImcMRNrT6BdgZY2Fdrsr/yazQh5/yuDzTEHug1QvEZ1QLzmL8j3LF5YTm7E7JEh FHAl6FM+WI+0n/ibEioAb/w+nrVLPbQG2IjLJL70yIIbq/J+Z+uW/1Kfc5ZNCShVPqvg pUPueR0lBehmB6V/99APUoQ/uIqVXGMhfYV5LnfU2Mrn1vISutM3JNn1J7ULaCc+q4e4 jvXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=/0PeDsqUvWY8Rmc0HQnOBmBLDJcNSSBrJMtjHVZ6l44=; b=E0Ex8duggTxTwIFvuj8Bm2xIoq2fPS2Jq8MyrPuVOK2hLN+DRfOUzWuFgS6xgOlLZd dafCyvU2Z/5AIjy8FJdJwrIWq+sawdGWEPxeQH6gHiWD/3dIAY1UPBH8McHSl2fkWwgk pKH5/vmC/v6+YhwFUam3L/ZXjQDi3PMFCI4Yi3qQO2aM0F7/5lJQaDOW9rd4OgCwpUtV U/tN7XjPpV+5ALPk9jaL66kYGQJvnBwdINCDvVYeuqhBAxjqac57Q4S6ONg4gmhEctRf ydm7uWUR5eb7epJvQeT9DzoMQ2NyrmCv1vxjW4yQglJ4IgZfpngsEutXmLhhyF9gOGv8 Nubw== X-Gm-Message-State: AIVw113MC5e1+WQMCq0C6Yf4xRLduPmLDZ5g66oIU/0D5A8CLChNYQSY d/YvwCedvHurm4rZ+y4= X-Received: by 10.28.211.10 with SMTP id k10mr1566474wmg.117.1498736942396; Thu, 29 Jun 2017 04:49:02 -0700 (PDT) Received: from ben.home (LFbn-1-11339-180.w2-15.abo.wanadoo.fr. [2.15.165.180]) by smtp.gmail.com with ESMTPSA id r142sm1148896wmg.24.2017.06.29.04.49.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Jun 2017 04:49:01 -0700 (PDT) From: Ben RUBSON Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I/O to pool appears to be hung, panic ! Message-Id: Date: Thu, 29 Jun 2017 13:48:59 +0200 To: Freebsd fs , freebsd-scsi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 11:49:05 -0000 Hello, One of my servers did a kernel panic last night, giving the following = message : panic: I/O to pool 'home' appears to be hung on vdev guid 122... at = '/dev/label/G23iscsi'. Pool is made like this : home mirror label/G13local label/G14local label/G23iscsi <-- busy disk label/G24iscsi mirror label/G15local label/G16local label/G25iscsi label/G26iscsi cache label/G10local label/G11local Kernel is then complaining about one of the 4 iSCSI disks in the pool. All these 4 disks come from another identical FreeBSD system (40G "no = latency" link). Here are some numbers regarding this disk, taken from the server hosting = the pool : (unfortunately not from the iscsi target server) https://s23.postimg.org/zd8jy9xaj/busydisk.png We clearly see that suddendly, disk became 100% busy, meanwhile CPU was = almost idle. No error message at all on both servers. SMART from the target disk is nice : SMART Health Status: OK Current Drive Temperature: 32 C Drive Trip Temperature: 85 C Manufactured in week 22 of year 2016 Specified cycle count over device lifetime: 50000 Accumulated start-stop cycles: 18 Specified load-unload count over device lifetime: 600000 Accumulated load-unload cycles: 2362 Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator =3D 5938879802638336 Error counter log: Errors Corrected by Total Correction = Gigabytes Total ECC rereads/ errors algorithm = processed uncorrected fast | delayed rewrites corrected invocations [10^9 = bytes] errors read: 0 14 0 14 488481 74496.712 = 0 write: 0 0 0 0 126701 18438.443 = 0 verify: 0 0 0 0 20107 0.370 = 0 Non-medium error count: 0 SMART Self-test log Num Test Status segment LifeTime = LBA_first_err [SK ASC ASQ] Description number (hours) # 1 Background long Completed - 7943 = - [- - -] # 2 Background long Completed - 7607 = - [- - -] # 3 Background long Completed - 7271 = - [- - -] The only log I have is the following stacktrace taken from the server = console : panic: I/O to pool 'home' appears to be hung on vdev guid 122... at = '/dev/label/G23iscsi'. cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff80b240f7 at kdb_backtrace+0x67 #1 0xffffffff80ad9462 at vpanic+0x182 #2 0xffffffff80ad92d3 at panic+0x43 #3 0xffffffff82238fa7 at vdev_deadman+0x127 #4 0xffffffff82238ec0 at vdev_deadman+0x40 #5 0xffffffff82238ec0 at vdev_deadman+0x40 #6 0xffffffff8222d0a6 at spa_deadman+0x86 #7 0xffffffff80af32da at softclock_call_cc+0x18a #8 0xffffffff80af3854 at softclock+0x94 #9 0xffffffff80a9348f at intr_event_execute_handlers+0x20f #10 0xffffffff80a936f6 at ithread_loop+0xc6 #11 0xffffffff80a900d5 at fork_exit+0x85 #12 0xffffffff80f846fe at fork_trampoline+0xe Uptime: 92d2h47m6s I would have been pleased to make a dump available. However, despite my (correct ?) configuration, server did not dump : (nevertheless, "sysctl debug.kdb.panic=3D1" make it to dump) # grep ^dump /boot/loader.conf /etc/rc.conf /boot/loader.conf:dumpdev=3D"/dev/mirror/swap" /etc/rc.conf:dumpdev=3D"AUTO" # gmirror list swap Components: 2 Balance: prefer Providers: 1. Name: mirror/swap Mediasize: 8589934080 (8.0G) Consumers: 1. Name: label/swap1 State: ACTIVE Priority: 0 2. Name: label/swap2 State: ACTIVE Priority: 1 I use default kernel, with a rebuilt zfs module : # uname -v FreeBSD 11.0-RELEASE-p8 #0: Wed Feb 22 06:12:04 UTC 2017 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC=20 I use the following iSCSI configuration, which disconnects the disks "as = soon as" they are unavailable : kern.iscsi.ping_timeout=3D5 kern.iscsi.fail_on_disconnection=3D1 kern.iscsi.iscsid_timeout=3D5 I then think disk was at least correctly reachable during these 20 busy = minutes. So, any idea why I could have faced this issue ? I would have thought ZFS would have taken the busy device offline, = instead of raising a panic. Perhaps it is already possible to make ZFS behave like this ? Thank you very much for your help & support ! Best regards, Ben From owner-freebsd-fs@freebsd.org Thu Jun 29 13:00:44 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22EEAD9D086 for ; Thu, 29 Jun 2017 13:00:44 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DD76383AFE for ; Thu, 29 Jun 2017 13:00:43 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.154.248] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1dQYnu-0000BF-Jh; Thu, 29 Jun 2017 14:44:14 +0200 Date: Thu, 29 Jun 2017 14:43:34 +0200 From: Fabian Keil To: Ben RUBSON Cc: Freebsd fs Subject: Re: I/O to pool appears to be hung, panic ! Message-ID: <20170629144334.1e283570@fabiankeil.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/OJk+2XZjp0fxqK3f3pBddNw"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:00:44 -0000 --Sig_/OJk+2XZjp0fxqK3f3pBddNw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ben RUBSON wrote: > One of my servers did a kernel panic last night, giving the following mes= sage : > panic: I/O to pool 'home' appears to be hung on vdev guid 122... at '/dev= /label/G23iscsi'. [...]=20 > Here are some numbers regarding this disk, taken from the server hosting = the pool : > (unfortunately not from the iscsi target server) > https://s23.postimg.org/zd8jy9xaj/busydisk.png >=20 > We clearly see that suddendly, disk became 100% busy, meanwhile CPU was a= lmost idle. >=20 > No error message at all on both servers. [...] > The only log I have is the following stacktrace taken from the server con= sole : > panic: I/O to pool 'home' appears to be hung on vdev guid 122... at '/dev= /label/G23iscsi'. > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff80b240f7 at kdb_backtrace+0x67 > #1 0xffffffff80ad9462 at vpanic+0x182 > #2 0xffffffff80ad92d3 at panic+0x43 > #3 0xffffffff82238fa7 at vdev_deadman+0x127 > #4 0xffffffff82238ec0 at vdev_deadman+0x40 > #5 0xffffffff82238ec0 at vdev_deadman+0x40 > #6 0xffffffff8222d0a6 at spa_deadman+0x86 > #7 0xffffffff80af32da at softclock_call_cc+0x18a > #8 0xffffffff80af3854 at softclock+0x94 > #9 0xffffffff80a9348f at intr_event_execute_handlers+0x20f > #10 0xffffffff80a936f6 at ithread_loop+0xc6 > #11 0xffffffff80a900d5 at fork_exit+0x85 > #12 0xffffffff80f846fe at fork_trampoline+0xe > Uptime: 92d2h47m6s >=20 > I would have been pleased to make a dump available. > However, despite my (correct ?) configuration, server did not dump : > (nevertheless, "sysctl debug.kdb.panic=3D1" make it to dump) > # grep ^dump /boot/loader.conf /etc/rc.conf > /boot/loader.conf:dumpdev=3D"/dev/mirror/swap" > /etc/rc.conf:dumpdev=3D"AUTO" You may want to look at the NOTES section in gmirror(8). =20 > I use default kernel, with a rebuilt zfs module : > # uname -v > FreeBSD 11.0-RELEASE-p8 #0: Wed Feb 22 06:12:04 UTC 2017 root@amd64-b= uilder.daemonology.net:/usr/obj/usr/src/sys/GENERIC=20 >=20 > I use the following iSCSI configuration, which disconnects the disks "as = soon as" they are unavailable : > kern.iscsi.ping_timeout=3D5 > kern.iscsi.fail_on_disconnection=3D1 > kern.iscsi.iscsid_timeout=3D5 >=20 > I then think disk was at least correctly reachable during these 20 busy m= inutes. >=20 > So, any idea why I could have faced this issue ? Is it possible that the system was under memory pressure? geli's use of malloc() is known to cause deadlocks under memory pressure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209759 Given that gmirror uses malloc() as well it probably has the same issue. > I would have thought ZFS would have taken the busy device offline, instea= d of raising a panic. > Perhaps it is already possible to make ZFS behave like this ? There's a tunable for this: vfs.zfs.deadman_enabled. If the panic is just a symptom of the deadlock it's unlikely to help though. Fabian --Sig_/OJk+2XZjp0fxqK3f3pBddNw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCWVT19wAKCRAFiohV/3dU nSQ3AJ9bMFFwKvq/wxnYqy32gYYAX3Bb4gCeK9TU0cgG2uVaREVQnFLWnjC/E7A= =bXQU -----END PGP SIGNATURE----- --Sig_/OJk+2XZjp0fxqK3f3pBddNw-- From owner-freebsd-fs@freebsd.org Thu Jun 29 13:36:50 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3896DD9DA79; Thu, 29 Jun 2017 13:36:50 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF9A784B72; Thu, 29 Jun 2017 13:36:49 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wr0-x22c.google.com with SMTP id 77so189723290wrb.1; Thu, 29 Jun 2017 06:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+McbihPIfeGbcGMjhpqCdlCVmu56lMnabX+qRvak6gA=; b=pyYZmvTpY7dmtUS9n4ncGm6giAdNt48yKoIuLdiMbqS6reZvnpNjrEmBgXdzMp46eG tPawmK6TDvaeZ8887eHzCP6AgWUAj5E1Rvi1uIhgYlYHYRGRw1a8SU3mi7JsR/JSnMn8 Gqs0I8hwFmIsVsl4bpz5AmSfz8f1Hh+uuLnTstu3yYqCJIzMvMVTSqd17h80/2GfNQgR LK9clCpjH9WnBERnPbF9FbcK8a9+RC29Bkb1T33pu+MysWu6WJkicg8Alh0hVymtuQJO dkIZXO3e/3HqSuAUBXNlwMYqenGboShzSVl+pd/US4yp8EgvTXYK/LUlO5V2EeVRpO3S Ej5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+McbihPIfeGbcGMjhpqCdlCVmu56lMnabX+qRvak6gA=; b=p5cxOjMt8eu7VVlvPrZg0D68pU6/4D9bgT0bmNeRI9EtJP/jbM0kT5OvmDXi1t9jBg 4kRxtRy/mZNAQRMN/K5AZnxOJHHJ8kT/3Xz0niDoHPq7pvRsibYXBEWehGmXBjpVoLBl OgvP3lgn4rIiSfbyzP6MQ7PcuwC5r8goPoMvmvQXX3Jh/Z54hgiwsykhXKRdNFbUlA/M JePcyyAO2suGmOknG9KggmNf101+oIpT66q71tcWi8SDgBtGQsAaNRRyADj/bNhtczRn iKLQnx85+ZtQBtOk+CQO8NOdYnTdDwnLE1i80qip//uGZ48nlLB9svSN4xjlUYiOxDp7 V1jQ== X-Gm-Message-State: AKS2vOwYt7y/W6mDHhXHsk8cDaAfAwiYbeGjqzwR5W2yxR2wPlpaRRLx 4nl9NJgd/q7+ynWQe/8= X-Received: by 10.223.143.10 with SMTP id p10mr21583804wrb.120.1498743407648; Thu, 29 Jun 2017 06:36:47 -0700 (PDT) Received: from ben.home (LFbn-1-11339-180.w2-15.abo.wanadoo.fr. [2.15.165.180]) by smtp.gmail.com with ESMTPSA id b197sm1498890wmb.4.2017.06.29.06.36.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Jun 2017 06:36:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I/O to pool appears to be hung, panic ! From: Ben RUBSON In-Reply-To: <20170629144334.1e283570@fabiankeil.de> Date: Thu, 29 Jun 2017 15:36:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170629144334.1e283570@fabiankeil.de> To: Freebsd fs , freebsd-scsi@freebsd.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 13:36:50 -0000 > On 29 Jun 2017, at 14:43, Fabian Keil = wrote: Thank you for your feedback Fabian. > Ben RUBSON wrote: >=20 >> One of my servers did a kernel panic last night, giving the following = message : >> panic: I/O to pool 'home' appears to be hung on vdev guid 122... at = '/dev/label/G23iscsi'. > [...]=20 >> Here are some numbers regarding this disk, taken from the server = hosting the pool : >> (unfortunately not from the iscsi target server) >> https://s23.postimg.org/zd8jy9xaj/busydisk.png >>=20 >> We clearly see that suddendly, disk became 100% busy, meanwhile CPU = was almost idle. >>=20 >> No error message at all on both servers. > [...] >> The only log I have is the following stacktrace taken from the server = console : >> panic: I/O to pool 'home' appears to be hung on vdev guid 122... at = '/dev/label/G23iscsi'. >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xffffffff80b240f7 at kdb_backtrace+0x67 >> #1 0xffffffff80ad9462 at vpanic+0x182 >> #2 0xffffffff80ad92d3 at panic+0x43 >> #3 0xffffffff82238fa7 at vdev_deadman+0x127 >> #4 0xffffffff82238ec0 at vdev_deadman+0x40 >> #5 0xffffffff82238ec0 at vdev_deadman+0x40 >> #6 0xffffffff8222d0a6 at spa_deadman+0x86 >> #7 0xffffffff80af32da at softclock_call_cc+0x18a >> #8 0xffffffff80af3854 at softclock+0x94 >> #9 0xffffffff80a9348f at intr_event_execute_handlers+0x20f >> #10 0xffffffff80a936f6 at ithread_loop+0xc6 >> #11 0xffffffff80a900d5 at fork_exit+0x85 >> #12 0xffffffff80f846fe at fork_trampoline+0xe >> Uptime: 92d2h47m6s >>=20 >> I would have been pleased to make a dump available. >> However, despite my (correct ?) configuration, server did not dump : >> (nevertheless, "sysctl debug.kdb.panic=3D1" make it to dump) >> # grep ^dump /boot/loader.conf /etc/rc.conf >> /boot/loader.conf:dumpdev=3D"/dev/mirror/swap" >> /etc/rc.conf:dumpdev=3D"AUTO" >=20 > You may want to look at the NOTES section in gmirror(8). Yes, I should already be OK (prefer algorithm set). >> I use default kernel, with a rebuilt zfs module : >> # uname -v >> FreeBSD 11.0-RELEASE-p8 #0: Wed Feb 22 06:12:04 UTC 2017 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC=20 >>=20 >> I use the following iSCSI configuration, which disconnects the disks = "as soon as" they are unavailable : >> kern.iscsi.ping_timeout=3D5 >> kern.iscsi.fail_on_disconnection=3D1 >> kern.iscsi.iscsid_timeout=3D5 >>=20 >> I then think disk was at least correctly reachable during these 20 = busy minutes. >>=20 >> So, any idea why I could have faced this issue ? >=20 > Is it possible that the system was under memory pressure? No I don't think it was : https://s1.postimg.org/uvsebpyyn/busydisk2.png More than 2GB of available memory. Swap not used (624kB). ARC behaviour seems correct (anon increases because ZFS can't actually = write I think). Regarding the pool itself, it was receiving data at 6MB/s, sending = around 30kB blocks to disks. When disk went busy, throughput fell to some kB, with 128kB blocks. > geli's use of malloc() is known to cause deadlocks under memory = pressure: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209759 >=20 > Given that gmirror uses malloc() as well it probably has the same = issue. I don't use geli so I should not face this issue. >> I would have thought ZFS would have taken the busy device offline, = instead of raising a panic. >> Perhaps it is already possible to make ZFS behave like this ? >=20 > There's a tunable for this: vfs.zfs.deadman_enabled. > If the panic is just a symptom of the deadlock it's unlikely > to help though. I think this tunable should have prevented the server from having raised = a panic : # sysctl -d vfs.zfs.deadman_enabled vfs.zfs.deadman_enabled: Kernel panic on stalled ZFS I/O # sysctl vfs.zfs.deadman_enabled vfs.zfs.deadman_enabled: 1 But not sure how it would have behaved then... (busy disk miraculously back to normal status, memory pressure due to = anon increasing...) I also tried to look for some LSI SAS2008 error counters (on target = side), but did not found anything interesting. (sysctl -a | grep -i mps) Thank you again, Ben From owner-freebsd-fs@freebsd.org Thu Jun 29 18:49:19 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7A05DA2FFC; Thu, 29 Jun 2017 18:49:19 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from mail.inparadise.se (h-246-50.A444.priv.bahnhof.se [155.4.246.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8732A6EA23; Thu, 29 Jun 2017 18:49:18 +0000 (UTC) (envelope-from karli@inparadise.se) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 822DE489C4; Thu, 29 Jun 2017 20:40:44 +0200 (CEST) Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9d2JQulMdY3v; Thu, 29 Jun 2017 20:40:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id AAA0C489C5; Thu, 29 Jun 2017 20:40:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.inparadise.se AAA0C489C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inparadise.se; s=ECF0F226-2F14-11E7-BBE9-ECFEB9BC1D67; t=1498761643; bh=9yazR+QulQ43ITdDjWG9Ngjsw2oS+5gYOLYKwpKRD1g=; h=Date:Message-ID:To:From:MIME-Version; b=1pEzq2qWIrvaRlN9pbTbKiaS6UfArx6QD2/uaFZzp4Eyc+Vi3pf4OGCFrBiyS592H AZ2y+ECav8z6Q6fPnLZTUdWU51gPiGguteaWpeKPvICmoSbTuE5YR6uKWQ/R/dp54R hg8l6x1MwlRRGeOdzJDNwFJPsFYPyLRjDTC3ivrO+4RQczNMDJwL/+UPR+EAPmO6vv 6CGNTyZopUNChvaTCzJMU3W+R7ky38Yl6vfdS1zprmqUC0MRkintO6BQS32LIOkeXu bM7LlQj0yTAKfnJkh8hmp83LkEqDL+yMLGs4zCnY+ipNqE0l+HF94v9UCbJcnW+OJu hCs8TeH8TPGSQ== X-Virus-Scanned: amavisd-new at inparadise.se Received: from mail.inparadise.se ([127.0.0.1]) by localhost (mail.inparadise.se [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L-VYpFlZt8xy; Thu, 29 Jun 2017 20:40:43 +0200 (CEST) Received: from mail.inparadise.se (localhost [127.0.0.1]) by mail.inparadise.se (Postfix) with ESMTP id 88D33489C4; Thu, 29 Jun 2017 20:40:43 +0200 (CEST) Date: Thu, 29 Jun 2017 20:40:43 +0200 (CEST) Subject: Re: I/O to pool appears to be hung, panic ! Message-ID: X-Android-Message-ID: To: Ben RUBSON Cc: freebsd-scsi@freebsd.org, Freebsd fs Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= X-Originating-IP: [172.16.1.154, 127.0.0.1] X-Mailer: Zimbra 8.7.1_GA_1670 (Android-Mail/7.6.4.158567011.release(...883836) devip=172.16.1.154 ZPZB/66) Thread-Index: elz8IC2KjbrK5W6ahkbM30aqsX5MTA== Thread-Topic: I/O to pool appears to be hung, panic ! MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 18:49:20 -0000 From owner-freebsd-fs@freebsd.org Sat Jul 1 14:13:18 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7757D8ABB8 for ; Sat, 1 Jul 2017 14:13:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95BCC2D45 for ; Sat, 1 Jul 2017 14:13:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v61EDIvN061168 for ; Sat, 1 Jul 2017 14:13:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220391] "gpart resize" = panic Date: Sat, 01 Jul 2017 14:13:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 14:13:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220391 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Jul 1 15:43:31 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DD83D8CAC0 for ; Sat, 1 Jul 2017 15:43:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BDC365A74 for ; Sat, 1 Jul 2017 15:43:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v61FhULe006392 for ; Sat, 1 Jul 2017 15:43:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 220391] "gpart resize" = panic Date: Sat, 01 Jul 2017 15:43:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 15:43:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220391 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-fs@FreeBSD.org |freebsd-geom@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.=