From owner-freebsd-fs@FreeBSD.ORG Sun Mar 8 00:09:44 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED2EFBF4; Sun, 8 Mar 2015 00:09:44 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB004929; Sun, 8 Mar 2015 00:09:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0218237B55B; Sat, 7 Mar 2015 18:01:32 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l02sR1WzVz22S; Sat, 7 Mar 2015 18:01:31 -0600 (CST) Date: Sat, 7 Mar 2015 18:01:31 -0600 From: "Matthew D. Fuller" To: freebsd-geom@freebsd.org Subject: RFC: Pass TRIM through GELI Message-ID: <20150308000131.GP1742@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean X-Mailman-Approved-At: Sun, 08 Mar 2015 03:39:00 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 00:09:45 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ bcc'd to -fs because it's been discussed there in the past; followup to -geom because that seems where it belongs ] I've done a quick implementation of TRIM passthru support for GELI. Patch attached is against late Feb -CURRENT; however, a glance at svn suggests this code hasn't changed much, so it's probably pretty portable forward and back. It applies cleanly to a stable/10 tree though I haven't tried compiling or using it there. This has been lightly tested and seems to work fine. It adds a '-t' flag to init and onetime to enable passthru on the new provider, and '-t/-T' options to configure to en/disable on existing (but see caveat below about metadata versions; as written, you can't use this on existing partitions). Since all we're doing is passing it through instead of denying it, I'd expect "seems to work" to be pretty much the same as "does work"; the requests go through, space clears up, and messing with a little ZFS on top of it doesn't show up any data corruption. The patch to gnop in is a useful adjunct in checking when/if the requests actually go through, by making the .eli on top of the .nop and seeing when the counters tick. In this implementation, I added a new G_ELI_VERSION and required it for setting the flag. I actually think this is probably not necessary; all we do is set a value in the flags field, and if it's loaded onto a system that doesn't know what to do with that value, it'll just do nothing, which IMO is fine. And since there is no `geli upgrade`, this means that you can't enable it on any existing partitions, but have to kill/init from scratch, which isn't very user-friendly. So I propose that it actually be done sans those version changes, but they are in the patch as attached for now. One not-quite-related change in here is that I added a denial for 'geli configure' attempts on onetime providers. Trying this causes a panic, as the metadata version field on onetime providers is nonsensical. As far as I can tell in quick testing, this isn't related to my changes; it happens with stock GELI code as well. Presumably it's never been noticed before since the only prior use for 'geli configure' was to un/set the BOOT flag, which makes no sense on a onetime anyway, so nobody ever bothered trying. But with -[tT], somebody might try. Evidence: I did, and found the panic :) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. --nVMJ2NtxeReIH9PS Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="geli-delete.patch" Index: sbin/geom/class/eli/geli.8 =================================================================== --- sbin/geom/class/eli/geli.8 (revision 279210) +++ sbin/geom/class/eli/geli.8 (working copy) @@ -51,7 +51,7 @@ .Pp .Nm .Cm init -.Op Fl bPv +.Op Fl bPtv .Op Fl a Ar aalgo .Op Fl B Ar backupfile .Op Fl e Ar ealgo @@ -80,7 +80,7 @@ .Cm detach .Nm .Cm onetime -.Op Fl d +.Op Fl dt .Op Fl a Ar aalgo .Op Fl e Ar ealgo .Op Fl l Ar keylen @@ -88,7 +88,7 @@ .Ar prov .Nm .Cm configure -.Op Fl bB +.Op Fl bBtT .Ar prov ... .Nm .Cm setkey @@ -351,6 +351,12 @@ Increasing the sector size allows increased performance, because encryption/decryption which requires an initialization vector is done per sector; fewer sectors means less computational work. +.It Fl t +Pass through BIO_DELETE calls (i.e., TRIM/UNMAP). +This can be useful when encrypting on a SSD, by allowing it to clean up +sectors you're no longer using. +It will, however, provide some information (how much space you're actually +using, and which sectors contain real data) to an attacker. .It Fl V Ar version Metadata version to use. This option is helpful when creating a provider that may be used by older @@ -456,6 +462,11 @@ For more information, see the description of the .Cm init subcommand. +.It Fl t +Enable TRIM/UNMAP passthru. +For more information, see the description of the +.Cm init +subcommand. .El .It Cm configure Change configuration of the given providers. @@ -469,6 +480,13 @@ subcommand. .It Fl B Remove the BOOT flag from the given providers. +.It Fl t +Enable TRIM/UNMAP passthru. +For more information, see the description of the +.Cm init +subcommand. +.It Fl T +Disable TRIM/UNMAP passthru. .El .It Cm setkey Install a copy of the Master Key into the selected slot, encrypted with Index: sbin/geom/class/eli/geom_eli.c =================================================================== --- sbin/geom/class/eli/geom_eli.c (revision 279210) +++ sbin/geom/class/eli/geom_eli.c (working copy) @@ -114,10 +114,11 @@ { 'l', "keylen", "0", G_TYPE_NUMBER }, { 'P', "nonewpassphrase", NULL, G_TYPE_BOOL }, { 's', "sectorsize", "0", G_TYPE_NUMBER }, + { 't', "trim", NULL, G_TYPE_BOOL }, { 'V', "mdversion", "-1", G_TYPE_NUMBER }, G_OPT_SENTINEL }, - "[-bPv] [-a aalgo] [-B backupfile] [-e ealgo] [-i iterations] [-l keylen] [-J newpassfile] [-K newkeyfile] [-s sectorsize] [-V version] prov" + "[-bPtv] [-a aalgo] [-B backupfile] [-e ealgo] [-i iterations] [-l keylen] [-J newpassfile] [-K newkeyfile] [-s sectorsize] [-V version] prov" }, { "label", G_FLAG_VERBOSE, eli_main, { @@ -170,17 +171,20 @@ { 'e', "ealgo", GELI_ENC_ALGO, G_TYPE_STRING }, { 'l', "keylen", "0", G_TYPE_NUMBER }, { 's', "sectorsize", "0", G_TYPE_NUMBER }, + { 't', "trim", NULL, G_TYPE_BOOL }, G_OPT_SENTINEL }, - "[-d] [-a aalgo] [-e ealgo] [-l keylen] [-s sectorsize] prov" + "[-dt] [-a aalgo] [-e ealgo] [-l keylen] [-s sectorsize] prov" }, { "configure", G_FLAG_VERBOSE, eli_main, { { 'b', "boot", NULL, G_TYPE_BOOL }, { 'B', "noboot", NULL, G_TYPE_BOOL }, + { 't', "trim", NULL, G_TYPE_BOOL }, + { 'T', "notrim", NULL, G_TYPE_BOOL }, G_OPT_SENTINEL }, - "[-bB] prov ..." + "[-bBtT] prov ..." }, { "setkey", G_FLAG_VERBOSE, eli_main, { @@ -698,6 +702,14 @@ md.md_flags = 0; if (gctl_get_int(req, "boot")) md.md_flags |= G_ELI_FLAG_BOOT; + if (gctl_get_int(req, "trim")) { + if (version < G_ELI_VERSION_08) { + gctl_error(req, "TRIM is supported starting from version %u.", + G_ELI_VERSION_08); + return; + } + md.md_flags |= G_ELI_FLAG_DELETE; + } md.md_ealgo = CRYPTO_ALGORITHM_MIN - 1; str = gctl_get_ascii(req, "aalgo"); if (*str != '\0') { @@ -899,26 +911,50 @@ } static void -eli_configure_detached(struct gctl_req *req, const char *prov, bool boot) +eli_configure_detached(struct gctl_req *req, const char *prov, int boot, + int trim) { struct g_eli_metadata md; + bool changed = 0; if (eli_metadata_read(req, prov, &md) == -1) return; - if (boot && (md.md_flags & G_ELI_FLAG_BOOT)) { + if (boot == 1 && (md.md_flags & G_ELI_FLAG_BOOT)) { if (verbose) printf("BOOT flag already configured for %s.\n", prov); - } else if (!boot && !(md.md_flags & G_ELI_FLAG_BOOT)) { + } else if (boot == 0 && !(md.md_flags & G_ELI_FLAG_BOOT)) { if (verbose) printf("BOOT flag not configured for %s.\n", prov); - } else { + } else if (boot >= 0) { if (boot) md.md_flags |= G_ELI_FLAG_BOOT; else md.md_flags &= ~G_ELI_FLAG_BOOT; + changed = 1; + } + + if (trim == 1 && (md.md_flags & G_ELI_FLAG_DELETE)) { + if (verbose) + printf("TRIM flag already configured for %s.\n", prov); + } else if (trim == 0 && !(md.md_flags & G_ELI_FLAG_DELETE)) { + if (verbose) + printf("TRIM flag not configured for %s.\n", prov); + } else if (trim >= 0) { + if(md.md_version < G_ELI_VERSION_08) { + printf("TRIM requires version %u, %s is %u\n", G_ELI_VERSION_08, + prov, md.md_version); + } else { + if (trim) + md.md_flags |= G_ELI_FLAG_DELETE; + else + md.md_flags &= ~G_ELI_FLAG_DELETE; + changed = 1; + } + } + + if(changed) eli_metadata_store(req, prov, &md); - } bzero(&md, sizeof(md)); } @@ -926,7 +962,8 @@ eli_configure(struct gctl_req *req) { const char *prov; - bool boot, noboot; + bool boot, noboot, trim, notrim; + int doboot, dotrim; int i, nargs; nargs = gctl_get_int(req, "nargs"); @@ -937,12 +974,30 @@ boot = gctl_get_int(req, "boot"); noboot = gctl_get_int(req, "noboot"); + trim = gctl_get_int(req, "trim"); + notrim = gctl_get_int(req, "notrim"); + doboot = -1; if (boot && noboot) { gctl_error(req, "Options -b and -B are mutually exclusive."); return; } - if (!boot && !noboot) { + if (boot) + doboot = 1; + else if (noboot) + doboot = 0; + + dotrim = -1; + if (trim && notrim) { + gctl_error(req, "Options -t and -T are mutually exclusive."); + return; + } + if (trim) + dotrim = 1; + else if (notrim) + dotrim = 0; + + if (doboot == -1 && dotrim == -1) { gctl_error(req, "No option given."); return; } @@ -953,7 +1008,7 @@ for (i = 0; i < nargs; i++) { prov = gctl_get_ascii(req, "arg%d", i); if (!eli_is_attached(prov)) - eli_configure_detached(req, prov, boot); + eli_configure_detached(req, prov, doboot, dotrim); } } Index: sys/geom/eli/g_eli.c =================================================================== --- sys/geom/eli/g_eli.c (revision 279210) +++ sys/geom/eli/g_eli.c (working copy) @@ -314,8 +314,11 @@ /* * We could eventually support BIO_DELETE request. * It could be done by overwritting requested sector with - * random data g_eli_overwrites number of times. + * random data g_eli_overwrites number of times. Or if the user + * has set the DELETE flag, we just pass it down the stack. */ + if (sc->sc_flags & G_ELI_FLAG_DELETE) + break; default: g_io_deliver(bp, EOPNOTSUPP); return; @@ -342,6 +345,7 @@ break; case BIO_GETATTR: case BIO_FLUSH: + case BIO_DELETE: cbp->bio_done = g_std_done; cp = LIST_FIRST(&sc->sc_geom->consumer); cbp->bio_to = cp->provider; @@ -1245,6 +1249,7 @@ ADD_FLAG(G_ELI_FLAG_WOPEN, "W-OPEN"); ADD_FLAG(G_ELI_FLAG_DESTROY, "DESTROY"); ADD_FLAG(G_ELI_FLAG_RO, "READ-ONLY"); + ADD_FLAG(G_ELI_FLAG_DELETE, "DELETE"); #undef ADD_FLAG } sbuf_printf(sb, "\n"); Index: sys/geom/eli/g_eli.h =================================================================== --- sys/geom/eli/g_eli.h (revision 279210) +++ sys/geom/eli/g_eli.h (working copy) @@ -70,6 +70,7 @@ * G_ELI_FLAG_FIRST_KEY flag will be set for older versions). * 7 - Encryption keys are now generated from the Data Key and not from the * IV Key (the G_ELI_FLAG_ENC_IVKEY flag will be set for older versions). + * 8 - Added G_ELI_FLAG_DELETE. */ #define G_ELI_VERSION_00 0 #define G_ELI_VERSION_01 1 @@ -79,7 +80,8 @@ #define G_ELI_VERSION_05 5 #define G_ELI_VERSION_06 6 #define G_ELI_VERSION_07 7 -#define G_ELI_VERSION G_ELI_VERSION_07 +#define G_ELI_VERSION_08 8 +#define G_ELI_VERSION G_ELI_VERSION_08 /* ON DISK FLAGS. */ /* Use random, onetime keys. */ @@ -94,6 +96,8 @@ #define G_ELI_FLAG_AUTH 0x00000010 /* Provider is read-only, we should deny all write attempts. */ #define G_ELI_FLAG_RO 0x00000020 +/* Pass through BIO_DELETE requests */ +#define G_ELI_FLAG_DELETE 0x00000040 /* RUNTIME FLAGS. */ /* Provider was open for writing. */ #define G_ELI_FLAG_WOPEN 0x00010000 @@ -242,7 +246,7 @@ *datap = p; } static __inline void -eli_metadata_encode_v1v2v3v4v5v6v7(struct g_eli_metadata *md, u_char **datap) +eli_metadata_encode_v1_to_8(struct g_eli_metadata *md, u_char **datap) { u_char *p; @@ -281,7 +285,8 @@ case G_ELI_VERSION_05: case G_ELI_VERSION_06: case G_ELI_VERSION_07: - eli_metadata_encode_v1v2v3v4v5v6v7(md, &p); + case G_ELI_VERSION_08: + eli_metadata_encode_v1_to_8(md, &p); break; default: #ifdef _KERNEL @@ -321,7 +326,7 @@ } static __inline int -eli_metadata_decode_v1v2v3v4v5v6v7(const u_char *data, struct g_eli_metadata *md) +eli_metadata_decode_v1_to_8(const u_char *data, struct g_eli_metadata *md) { MD5_CTX ctx; const u_char *p; @@ -364,7 +369,8 @@ case G_ELI_VERSION_05: case G_ELI_VERSION_06: case G_ELI_VERSION_07: - error = eli_metadata_decode_v1v2v3v4v5v6v7(data, md); + case G_ELI_VERSION_08: + error = eli_metadata_decode_v1_to_8(data, md); break; default: error = EOPNOTSUPP; Index: sys/geom/eli/g_eli_ctl.c =================================================================== --- sys/geom/eli/g_eli_ctl.c (revision 279210) +++ sys/geom/eli/g_eli_ctl.c (working copy) @@ -236,7 +236,7 @@ const char *name; intmax_t *keylen, *sectorsize; u_char mkey[G_ELI_DATAIVKEYLEN]; - int *nargs, *detach; + int *nargs, *detach, *trim; g_topology_assert(); bzero(&md, sizeof(md)); @@ -256,6 +256,11 @@ gctl_error(req, "No '%s' argument.", "detach"); return; } + trim = gctl_get_paraml(req, "trim", sizeof(*trim)); + if (detach == NULL) { + gctl_error(req, "No '%s' argument.", "trim"); + return; + } strlcpy(md.md_magic, G_ELI_MAGIC, sizeof(md.md_magic)); md.md_version = G_ELI_VERSION; @@ -262,6 +267,8 @@ md.md_flags |= G_ELI_FLAG_ONETIME; if (*detach) md.md_flags |= G_ELI_FLAG_WO_DETACH; + if (*trim) + md.md_flags |= G_ELI_FLAG_DELETE; md.md_ealgo = CRYPTO_ALGORITHM_MIN - 1; name = gctl_get_asciiparam(req, "aalgo"); @@ -377,11 +384,13 @@ char param[16]; const char *prov; u_char *sector; - int *nargs, *boot, *noboot; + int *nargs, *boot, *noboot, *trim, *notrim; int error; + int changed; u_int i; g_topology_assert(); + changed = 0; nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); if (nargs == NULL) { @@ -407,7 +416,27 @@ gctl_error(req, "Options -b and -B are mutually exclusive."); return; } - if (!*boot && !*noboot) { + if (*boot || *noboot) + changed = 1; + + trim = gctl_get_paraml(req, "trim", sizeof(*trim)); + if (trim == NULL) { + gctl_error(req, "No '%s' argument.", "trim"); + return; + } + notrim = gctl_get_paraml(req, "notrim", sizeof(*notrim)); + if (notrim == NULL) { + gctl_error(req, "No '%s' argument.", "notrim"); + return; + } + if (*trim && *notrim) { + gctl_error(req, "Options -t and -T are mutually exclusive."); + return; + } + if (*trim || *notrim) + changed = 1; + + if (!changed) { gctl_error(req, "No option given."); return; } @@ -429,20 +458,41 @@ "provider %s.", prov); continue; } + if (sc->sc_flags & G_ELI_FLAG_RO) { + gctl_error(req, "Cannot change configuration of " + "read-only provider %s.", prov); + continue; + } + if (sc->sc_flags & G_ELI_FLAG_ONETIME) { + gctl_error(req, "Cannot change configuration of " + "onetime provider %s.", prov); + continue; + } + if (*boot && (sc->sc_flags & G_ELI_FLAG_BOOT)) { G_ELI_DEBUG(1, "BOOT flag already configured for %s.", prov); continue; - } else if (!*boot && !(sc->sc_flags & G_ELI_FLAG_BOOT)) { + } else if (*noboot && !(sc->sc_flags & G_ELI_FLAG_BOOT)) { G_ELI_DEBUG(1, "BOOT flag not configured for %s.", prov); continue; } - if (sc->sc_flags & G_ELI_FLAG_RO) { - gctl_error(req, "Cannot change configuration of " - "read-only provider %s.", prov); + + if (*trim && (sc->sc_flags & G_ELI_FLAG_DELETE)) { + G_ELI_DEBUG(1, "TRIM flag already configured for %s.", + prov); continue; + } else if (*notrim && !(sc->sc_flags & G_ELI_FLAG_DELETE)) { + G_ELI_DEBUG(1, "TRIM flag not configured for %s.", + prov); + continue; + } else if ((*trim || *notrim) && sc->sc_version < G_ELI_VERSION_08) { + gctl_error(req, "TRIM requires version %u, %s is %u.", + G_ELI_VERSION_08, prov, sc->sc_version); + continue; } + cp = LIST_FIRST(&sc->sc_geom->consumer); pp = cp->provider; error = g_eli_read_metadata(mp, pp, &md); @@ -456,11 +506,19 @@ if (*boot) { md.md_flags |= G_ELI_FLAG_BOOT; sc->sc_flags |= G_ELI_FLAG_BOOT; - } else { + } else if (*noboot) { md.md_flags &= ~G_ELI_FLAG_BOOT; sc->sc_flags &= ~G_ELI_FLAG_BOOT; } + if (*trim) { + md.md_flags |= G_ELI_FLAG_DELETE; + sc->sc_flags |= G_ELI_FLAG_DELETE; + } else if (*notrim) { + md.md_flags &= ~G_ELI_FLAG_DELETE; + sc->sc_flags &= ~G_ELI_FLAG_DELETE; + } + sector = malloc(pp->sectorsize, M_ELI, M_WAITOK | M_ZERO); eli_metadata_encode(&md, sector); error = g_write_data(cp, pp->mediasize - pp->sectorsize, sector, --nVMJ2NtxeReIH9PS-- From owner-freebsd-fs@FreeBSD.ORG Sun Mar 8 16:03:56 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3A079EF for ; Sun, 8 Mar 2015 16:03:56 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B430E87 for ; Sun, 8 Mar 2015 16:03:56 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id EEA3B3592EE for ; Sun, 8 Mar 2015 17:03:52 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id D86C728494; Sun, 8 Mar 2015 17:03:52 +0100 (CET) Date: Sun, 8 Mar 2015 17:03:52 +0100 From: Jilles Tjoelker To: freebsd-fs@FreeBSD.org Subject: [patch] restore(8) nanosecond timestamps Message-ID: <20150308160352.GA69376@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:03:56 -0000 Hi, /sbin/restore rounds down timestamps to the microsecond. Now that we have futimens() and utimensat(), we can set timestamps to the nanosecond. A patch is at https://reviews.freebsd.org/D2020 . Please review. -- Jilles Tjoelker From owner-freebsd-fs@FreeBSD.ORG Sun Mar 8 21:00:06 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC6ACAE9 for ; Sun, 8 Mar 2015 21:00:06 +0000 (UTC) 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 A0D5C665 for ; Sun, 8 Mar 2015 21:00:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t28L06H2092743 for ; Sun, 8 Mar 2015 21:00:06 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503082100.t28L06H2092743@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 X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 08 Mar 2015 21:00:06 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 21:00:06 -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 ------------+-----------+--------------------------------------------------- Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 3 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 9 09:08:11 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B4EF56B for ; Mon, 9 Mar 2015 09:08:11 +0000 (UTC) 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 7294E8F7 for ; Mon, 9 Mar 2015 09:08:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2998Be4001536 for ; Mon, 9 Mar 2015 09:08:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Mon, 09 Mar 2015 09:08:11 +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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rs@bytecamp.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 09:08:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 Robert Schulze changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rs@bytecamp.net --- Comment #3 from Robert Schulze --- We have the same behaviour here, with an Intel SSDSA2M080G2GC as L2ARC. In the past, this led to serious performance degradation and a crash of the system. The behaviour is better since 10.1, but not fixed entirely. with kind regards, Robert Schulze -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 01:45:04 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7516265 for ; Tue, 10 Mar 2015 01:45:04 +0000 (UTC) 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 BD9C3326 for ; Tue, 10 Mar 2015 01:45:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2A1j4Ve040081 for ; Tue, 10 Mar 2015 01:45:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198231] [unionfs] deadlock Date: Tue, 10 Mar 2015 01:45:05 +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: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 01:45:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198231 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 07:39:50 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3346DE0 for ; Tue, 10 Mar 2015 07:39:50 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6FD5ACB6 for ; Tue, 10 Mar 2015 07:39:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t2A7dGQb047565; Tue, 10 Mar 2015 10:39:16 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 10 Mar 2015 10:39:16 +0300 (MSK) From: Dmitry Morozovsky To: Konstantin Belousov Subject: Re: mounting sun UFS file system under FreeBSD stable/10 In-Reply-To: Message-ID: References: <54F1FF4A.6040905@yandex.ru> <20150228181350.GT2379@kib.kiev.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 10 Mar 2015 10:39:16 +0300 (MSK) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 07:39:51 -0000 On Sat, 28 Feb 2015, Dmitry Morozovsky wrote: > > > It looks like VTOC disklabel, try to kldload geom_part_vtoc8. > > > > > > > It still cannot help, note that UFS image is big-endian, while > > the host is most likely x86, which means little-endian. Our UFS > > does not perform data normalization. > > I'm afraid of the same :( > > > Also, I believe that Sun did some changes to the filesystem layout, > > so it is not quite likely that it would work even on right endianess > > machine. Best action is to use Solaris live CD to tar the volume. > > Side question: can Solaris LiveCD use iSCSI-exported volume? I then could boot > Solaris in virtual machine and try to mount the .img from there... For the reference and search machines: Solaris/x86 and variants could *not* mount big-endian UFS; however, Debian successfuly detects and mounts them (read-only, but this was all I needed) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 11:02:37 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90DF2CA3 for ; Tue, 10 Mar 2015 11:02:37 +0000 (UTC) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9C587D for ; Tue, 10 Mar 2015 11:02:37 +0000 (UTC) Received: from localhost (f1e.forteasig.com [81.181.146.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id A698C2BFEF7 for ; Tue, 10 Mar 2015 13:01:13 +0200 (EET) Date: Tue, 10 Mar 2015 12:55:28 +0200 From: Ion-Mihai Tetcu To: freebsd-fs@FreeBSD.org Subject: Recovering zfs send | recv Message-ID: <20150310125528.000025b2@FreeBSD.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 11:02:37 -0000 Hi, Is there a way to "recover" from deleting a filesystem on the receiving side (also deleted on the sending side) so that replication can go on without receive -F? Now it fails with 'Filesystem modified since most recent snapshot'. I have no problem with rolling back (destroying) some last snapshots on the receiving side, but I can't use -F because it would remove about a year of "archived" snapshots that are no longer present on the sending side (where only the snapshots from the last 4 months are kept, mostly for space and performance reason - recursive snaps are being created each 10 minutes and their "archive" on the receving side currently numbers about 400.000 snaps.). On the sending side: pool/fs@s1 pool/fs/sfsA@s1 pool/fs/sfsB@s1 pool/fs/sfsD@s1 pool/fs@s2 pool/fs/sfsA@s2 pool/fs/sfsB@s2 pool/fs/sfsD@s2 <--- moment in time when 'zfs destroy -r pool/fs/sfsC' pool/fs@s3 pool/fs/sfsA@s3 pool/fs/sfsB@s3 pool/fs/sfsD@s3 pool/fs@s4 pool/fs/sfsA@s4 pool/fs/sfsB@s4 pool/fs/sfsD@s4 On the receiving side: BK/pool/fs@s1 BK/pool/fs/sfsA@s1 BK/pool/fs/sfsB@s1 BK/pool/fs/sfsD@s1 BK/pool/fs@s2 BK/pool/fs/sfsA@s2 BK/pool/fs/sfsB@s2 BK/pool/fs/sfsD@s2 <--- moment in time when 'zfs destroy -r BK/pool/fs/sfsC' zfs send -R -I pool/fs@s1 poll/fs@s2 | zfs receive -v -d BK works zfs send -R -I pool/fs@s2 poll/fs@s3 | zfs receive -v -d BK doens't In the worse case I could send | recv the child filesystems sfsA, sfsB, etc. (with I know it works) but given their number (and rather frequent zfs rename'ing of them on the sending side) it would be rather inconvenient. And, if it is not possible, what is the correct way of removing a filesystem on both sides that would allow replication to continue? Thanks, -- IOnut From owner-freebsd-fs@FreeBSD.ORG Tue Mar 10 15:07:48 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 766256AB for ; Tue, 10 Mar 2015 15:07:48 +0000 (UTC) Received: from gate.pik.ru (gate.pik.ru [IPv6:2a03:5a00:31:40::25]) (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 2D998B99 for ; Tue, 10 Mar 2015 15:07:48 +0000 (UTC) Received: from [internal] by relay.pik.ru (Postfix) with ESMTP id 0CCB124DF for ; Tue, 10 Mar 2015 18:07:43 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hotplug.ru; s=mx; t=1426000064; bh=pnphQIj/uSda9pyOagJKLuxm8x2v6XDHWdE1GO7+WbY=; h=Date:From:To:Subject:References:In-Reply-To; b=KhX3RYZaaRvAs+UCBTCRiCTGq6TXov90uZG3a/iFa7rhBrTgiZ6fdD7C0AGyU3/wo nGemm6wmx8D94rQjX8kmoQ8tUorx9/6qxHyBKgXurrTsoQQ3QlOlc+39D//0Kh8Bwd 486XTcS+5p7+zsAor8AQBQe7NCREfDg92CtWsWNk= Message-ID: <54FF08BF.6030001@hotplug.ru> Date: Tue, 10 Mar 2015 18:07:43 +0300 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS Deadlock? References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 15:07:48 -0000 On 07.03.2015 06:13, Nick Sivo wrote: > Hi, > > One of our servers occasionally exhibits strange behavior under heavy > IO load. I think, based on the output from procstat -kk -a, it may be > a ZFS or VFS deadlock. Certain operations, including anything > involving the ZFS commands like zfs and zpool will hang. Running ls at > the root of a ZFS filesystem will also hang. Trying to access > snapshots in the .zfs/ folder will hang. None of these hung processes > can be killed. Eventually the machine will panic, if we don't reboot > it first, but that can take days after we start seeing this issue. > Strangely, our primary application (Hacker News) will keep running > without interruption until the panic. > > Hi. What is your hw specs (controller/drives)? I had an issues like yours some time ago with one of my storages. Not sure what was the cause of it, there were some parts replaced. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 04:43:06 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF41FD5C for ; Thu, 12 Mar 2015 04:43:06 +0000 (UTC) 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 940EE5FB for ; Thu, 12 Mar 2015 04:43:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C4h6Hp008957 for ; Thu, 12 Mar 2015 04:43:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194479] many file i/o operations hanging: softdepflush, suspfs Date: Thu, 12 Mar 2015 04:43:05 +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: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:43:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194479 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 04:58:28 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16B02904 for ; Thu, 12 Mar 2015 04:58:28 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 D016A7F9 for ; Thu, 12 Mar 2015 04:58:27 +0000 (UTC) Received: by padfa1 with SMTP id fa1so17359286pad.3 for ; Wed, 11 Mar 2015 21:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ycombinator.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=g7aKifHXf+qbeWIYJu+FqwICh1mHsMCleKVIXjfQhD8=; b=F5aZ490RAU66FC7GCGDr/vzewUHHgK+QMUwSqtr5hVQtf/2nWlKQmAmvD+sN3sZv8r ZLJZAfIGicztx+U4mOLkoFD7dj9qzZZZxTIoA7Depf9srQMba14nDsYLtmfmRvUvk8Df Wsq9Qbs7OoqdjPPboCK2hLXonMgpdxDoROGP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=g7aKifHXf+qbeWIYJu+FqwICh1mHsMCleKVIXjfQhD8=; b=m1X05gQ8DLQYZanfWdhObCauHJMG+FSfZ0sEbCBlplBCexmZ5RNHWoUxRact3uV9aD SKJNuhM7GgahGlJQyk/76Tq8TkakMspVBKEX+9SgEAAKlYNc2cln+kLq+f1Bb52D7wwN sbqPZs1PtRLvPIji3FzNXUBCydBnZljHpjCOHyksnj0UBM0tIvMxN/QjS/wPonk+syAO ieogWNWE1H1bJhUEFsctWabpJ5PXKxqmCqf3A2BKY5TkDRRr7j5AN1asdOpThHDYYRB6 KlqNdOCG/Gh5EtgP/no86/tg6AuNty4c0PWu22HveRcklVm6B7TCVCp3LabPQyKxNVCo Wprw== X-Gm-Message-State: ALoCoQlcqcKhQd0Pk4mkMUUMtRX9V6xITaQaXslsxEFhldWR2Yal79E6ZZhibyKpE94BXHob4/pu MIME-Version: 1.0 X-Received: by 10.70.133.130 with SMTP id pc2mr84035170pdb.99.1426136306820; Wed, 11 Mar 2015 21:58:26 -0700 (PDT) Received: by 10.70.36.230 with HTTP; Wed, 11 Mar 2015 21:58:26 -0700 (PDT) In-Reply-To: References: <54FAD0B2.8060601@multiplay.co.uk> <54FAD47B.7090007@sorbs.net> <54FADEBF.2060905@multiplay.co.uk> <54FAE018.8080509@sorbs.net> <54FAE513.3030107@multiplay.co.uk> Date: Wed, 11 Mar 2015 21:58:26 -0700 Message-ID: Subject: Re: ZFS Deadlock? From: Nick Sivo To: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:58:28 -0000 We've got Racket running on 10.1 and are planning to switch over tonight. I'll come back with new stack traces and logs if we encounter similar problems. Thanks! -Nick On Sat, Mar 7, 2015 at 2:54 PM, Nick Sivo wrote: > Unfortunately in our case we can't easily upgrade to 10 or 10.1 > because Racket (6.1.1) on them isn't stable and core dumps. Fixing > Racket trunk on FreeBSD 10+ was not the next step I expected, > especially since 9.3 is still considered "supported" for nearly two > more years. > > Not what I wanted to hear, but good to know regardless. Thanks! > > -Nick > > On Sat, Mar 7, 2015 at 3:46 AM, Steven Hartland wrote: >> >> >> On 07/03/2015 11:25, Michelle Sullivan wrote: >>> >>> Steven Hartland wrote: >>>> >>>> >>>> On 07/03/2015 10:35, Michelle Sullivan wrote: >>>>> >>>>> Steven Hartland wrote: >>>>>> >>>>>> There are lots of fixes for ZFS issues in 10 so I'd recommend updated >>>>>> to 10.1-RELEASE to see if you issue is already resolved there. >>>>>> >>>>> Question is will the fixes be applied to 9.4? Will there be a 9.4? >>>>> >>>> Unlikely I now any changes I've been doing I've only been MFC'ing to >>>> 10 not 9 or 8. >>> >>> I wouldn't expect 8 being that it's already at 8.4 therefore no more >>> releases just patches... but are we not getting a 9.4? Should not the >>> known issues that have been addresses have their fixes integrated? >>> >> I couldn't comment on if there will be a 9.4, even if there is I wouldn't >> expect all the fixes that are in 10 to be present if I'm honest, the team >> only has so much time so prioritising the latest releases is just something >> that's going to have to happen. >> >> We're already had 10 and now 10.1 I'd say its time to upgrade ;-) >> >> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:00:58 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E025CB5F for ; Thu, 12 Mar 2015 05:00:58 +0000 (UTC) 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 C6621832 for ; Thu, 12 Mar 2015 05:00:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C50wkA087948 for ; Thu, 12 Mar 2015 05:00:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198457] zfs acl lost after zfs send-receive. Kernel panic Date: Thu, 12 Mar 2015 05:00:59 +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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:00:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198457 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:07:29 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28993CB3 for ; Thu, 12 Mar 2015 05:07:29 +0000 (UTC) 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 0F008900 for ; Thu, 12 Mar 2015 05:07:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C57SLD045996 for ; Thu, 12 Mar 2015 05:07:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197821] zfs list -t bookmark doesn't work on zvol Date: Thu, 12 Mar 2015 05:07:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:07:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197821 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:07:43 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9C20D68 for ; Thu, 12 Mar 2015 05:07:43 +0000 (UTC) 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 8D858908 for ; Thu, 12 Mar 2015 05:07:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C57hMK052156 for ; Thu, 12 Mar 2015 05:07:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197792] When attempting to mount a filesystem read-only the system hangs. Date: Thu, 12 Mar 2015 05:07:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:07:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197792 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:07:55 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 324D2E1C for ; Thu, 12 Mar 2015 05:07:55 +0000 (UTC) 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 17DD0910 for ; Thu, 12 Mar 2015 05:07:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C57sBt056193 for ; Thu, 12 Mar 2015 05:07:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197789] (zfs+i386 No PAE) panic: kmem_malloc(36864): kmem_map too small: 431976448 total allocated Date: Thu, 12 Mar 2015 05:07:54 +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: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:07:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197789 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:08:36 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 478FDED8 for ; Thu, 12 Mar 2015 05:08:36 +0000 (UTC) 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 2DC15920 for ; Thu, 12 Mar 2015 05:08:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C58ags075830 for ; Thu, 12 Mar 2015 05:08:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197513] zpool status prints non-helpful block size warnings on CCISS volumes Date: Thu, 12 Mar 2015 05:08:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:08:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197513 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:08:50 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2707FF8B for ; Thu, 12 Mar 2015 05:08:50 +0000 (UTC) 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 0D1DA928 for ; Thu, 12 Mar 2015 05:08:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C58naq082207 for ; Thu, 12 Mar 2015 05:08:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197364] ZPOOL EXPORT POOL command fails to export pool from removed device Date: Thu, 12 Mar 2015 05:08: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: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:08:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197364 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:10:05 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E95B167 for ; Thu, 12 Mar 2015 05:10:05 +0000 (UTC) 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 E9061945 for ; Thu, 12 Mar 2015 05:10:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5A4eu003430 for ; Thu, 12 Mar 2015 05:10:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197170] [nfs] Kernel panic when receiving invalid RPC requests Date: Thu, 12 Mar 2015 05:10:04 +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: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:10:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197170 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:10:15 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3971821F for ; Thu, 12 Mar 2015 05:10:15 +0000 (UTC) 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 1DB7A94D for ; Thu, 12 Mar 2015 05:10:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5AE6D007979 for ; Thu, 12 Mar 2015 05:10:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 197141] External UFS Formatted USB Drive confuses ZFS Boot Loader Date: Thu, 12 Mar 2015 05:10:15 +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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:10:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197141 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:11:30 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E14F48C for ; Thu, 12 Mar 2015 05:11:30 +0000 (UTC) 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 541C8A12 for ; Thu, 12 Mar 2015 05:11:30 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5BULF044808 for ; Thu, 12 Mar 2015 05:11:30 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 196799] Lock order reversal after shutting down ZFS root system. Date: Thu, 12 Mar 2015 05:11:30 +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-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:11:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196799 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:11:44 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A559B545 for ; Thu, 12 Mar 2015 05:11:44 +0000 (UTC) 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 8B679A1B for ; Thu, 12 Mar 2015 05:11:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5Bifx046336 for ; Thu, 12 Mar 2015 05:11:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 196726] fusefs truncates files on read, sometimes returns wrong data. Date: Thu, 12 Mar 2015 05:11:44 +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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:11:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196726 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 05:12:15 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D647C66C for ; Thu, 12 Mar 2015 05:12:15 +0000 (UTC) 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 BCDEFA30 for ; Thu, 12 Mar 2015 05:12:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2C5CFnH053659 for ; Thu, 12 Mar 2015 05:12:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 196533] ZFS Clone Core Dump Date: Thu, 12 Mar 2015 05:12:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:12:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196533 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 12 21:19:11 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6867EF7; Thu, 12 Mar 2015 21:19:11 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 78F81C61; Thu, 12 Mar 2015 21:19:11 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so59035138iec.0; Thu, 12 Mar 2015 14:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fdeUtvO1iPw8BW73spSiU4EJKw7heAGh8htKbf4ZpIg=; b=Km7g3O4TN7A0S5X0vTBA7GSjGXL94PAsu4hcR0HBGvhqgkiAAqo/C6URYNQ+VMdNS8 MWv6N9BeJm/1hVzinKd/koHJOkhb2aEMHp2uD7b+As0hK7MMjmXibke+D04UG31+mosi sPxEJXWt1PwyE3YAt4wuMD0IkPSgyrgwloBHApXug8bP1TAHMWbE5L2YacFhv+xlj/Pu UJOk/kTywXuwp5VqSbS1IC57ZL/JYY6da9lpxf3NYet54/UJpAtWBv60GGzuNDoXAy/e /ztGgd9IvrpR5rcNrUWeTRsCj4V5ZVSqnnLnaxbUN+sSPWaLwQX9ncZzDjwON0bj4hPl 1HmA== MIME-Version: 1.0 X-Received: by 10.50.111.10 with SMTP id ie10mr103618069igb.15.1426195150618; Thu, 12 Mar 2015 14:19:10 -0700 (PDT) Received: by 10.36.104.78 with HTTP; Thu, 12 Mar 2015 14:19:10 -0700 (PDT) Date: Thu, 12 Mar 2015 17:19:10 -0400 Message-ID: Subject: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hardware@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:19:11 -0000 Here is a performance review of the ST8000AS0002 non-SED "drive managed" model (caveat your actual expected usage). http://www.storagereview.com/seagate_archive_hdd_review_8tb You can also find these drives inside the STDT8000100 external USB unit for a bit more at $300. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 13:28:44 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AC55321 for ; Fri, 13 Mar 2015 13:28:44 +0000 (UTC) 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 80C3E8C7 for ; Fri, 13 Mar 2015 13:28:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DDSiDS091032 for ; Fri, 13 Mar 2015 13:28:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 195485] [ufs] mksnap_ffs(8) cannot create snapshot with journaled soft updates enabled Date: Fri, 13 Mar 2015 13:28:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:28:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195485 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 13:29:12 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C55403D7 for ; Fri, 13 Mar 2015 13:29:12 +0000 (UTC) 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 A56E58D9 for ; Fri, 13 Mar 2015 13:29:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DDTCOW091803 for ; Fri, 13 Mar 2015 13:29:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 195303] [zfs] large_blocks enabled on pool, recordsize capped at 1M, minor typo in error message when attempting to create dataset with recordsize=2M Date: Fri, 13 Mar 2015 13:29:12 +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-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:29:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195303 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Summary|large_blocks enabled on |[zfs] large_blocks enabled |pool, recordsize capped at |on pool, recordsize capped |1M, minor typo in error |at 1M, minor typo in error |message when attempting to |message when attempting to |create dataset with |create dataset with |recordsize=2M |recordsize=2M -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 13:30:49 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E57B75F7 for ; Fri, 13 Mar 2015 13:30:49 +0000 (UTC) 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 CBE0C8FD for ; Fri, 13 Mar 2015 13:30:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DDUnQL097660 for ; Fri, 13 Mar 2015 13:30:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194541] Cannot export zpool while completely unrelated mounted nfs is not responding Date: Fri, 13 Mar 2015 13:30:49 +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: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:30:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194541 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 13:31:07 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B401A6AF for ; Fri, 13 Mar 2015 13:31:07 +0000 (UTC) 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 9A71390C for ; Fri, 13 Mar 2015 13:31:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DDV7Zp098737 for ; Fri, 13 Mar 2015 13:31:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194513] zfs recv hangs in state kmem arena Date: Fri, 13 Mar 2015 13:31:06 +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: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:31:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 13:32:09 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B71AE784 for ; Fri, 13 Mar 2015 13:32:09 +0000 (UTC) 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 9D86B9AE for ; Fri, 13 Mar 2015 13:32:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DDW9e4000972 for ; Fri, 13 Mar 2015 13:32:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194293] FUSE program freezes when seeking pos > file size Date: Fri, 13 Mar 2015 13:32:09 +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: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 13:32:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194293 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 15:19:27 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEFF6A7D for ; Fri, 13 Mar 2015 15:19:27 +0000 (UTC) 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 B4E877B9 for ; Fri, 13 Mar 2015 15:19:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DFJRgT095287 for ; Fri, 13 Mar 2015 15:19:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 117158] [zfs] [panic] zpool scrub causes panic if geli vdevs detach on last close Date: Fri, 13 Mar 2015 15:19:27 +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: 7.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: woodsb02@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:19:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117158 pjd@FreeBSD.org changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |pjd@FreeBSD.org Ben Woods changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |woodsb02@gmail.com --- Comment #2 from pjd@FreeBSD.org --- Responsible Changed From-To: freebsd-bugs->pjd I'll take this one. --- Comment #3 from Ben Woods --- This bug bit me today - it is quite unnerving to watch your zpool go offline due to unavailable devices, all from initiating a simply scrub! However, I can confirm that a reboot recovered the zpool successfully, and adding the following to /etc/rc.conf prevented it from happening again during the next zpool scrub: geli_autodetach="NO" Note: I rebooted once more after adding that to /etc/rc.conf and before initiating the next zpool scrub, just in case that configuration parameter is only read at boot time or the time the geli is attached. Not sure if that was required. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 15:20:25 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B13DB43 for ; Fri, 13 Mar 2015 15:20:25 +0000 (UTC) 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 10F177CC for ; Fri, 13 Mar 2015 15:20:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DFKO7x096833 for ; Fri, 13 Mar 2015 15:20:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 117158] [zfs] [panic] zpool scrub causes panic if geli vdevs detach on last close Date: Fri, 13 Mar 2015 15:20:25 +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: 7.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: woodsb02@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:20:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=117158 --- Comment #4 from Ben Woods --- I should add that I am running FreeBSD 10.1 amd64 with generic kernel/world. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 13 17:08:01 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1956852; Fri, 13 Mar 2015 17:08:01 +0000 (UTC) Received: from gate.pik.ru (gate.pik.ru [IPv6:2a03:5a00:31:40::25]) (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 1A3F2653; Fri, 13 Mar 2015 17:08:00 +0000 (UTC) Received: from [internal] by relay.pik.ru (Postfix) with ESMTP id B5A38107C9; Fri, 13 Mar 2015 20:07:54 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hotplug.ru; s=mx; t=1426266475; bh=qvlcOkMWfeyqUMT3l1QcpG/IxkeDFq6JDHtWzCItWm0=; h=Date:From:To:Subject:References:In-Reply-To; b=PZwhRKa0Ng+NX62iSg2fAENzZPTaHGSHdeOOyseesyKmmjOkcsjWz/kdRDGH8S0i0 l5JIwDZTXtWV5VRoLIvd53Zci8rTeF3GEx0EeAI6joTXK72n6gD+SpyRcgCPj09VS3 MFdvB8U9Ln7T+C3RGwgGkMnn/M0b0cr399Tyenc8= Message-ID: <5503196A.3090504@hotplug.ru> Date: Fri, 13 Mar 2015 20:07:54 +0300 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexander Motin , freebsd-fs@freebsd.org Subject: Re: CAM Target over FC and UNMAP problem References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> In-Reply-To: <54F98135.5000908@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:08:01 -0000 Hi Alexander, thanks for your comments, I'm still working on this On 06.03.2015 13:28, Alexander Motin wrote: > On 06.03.2015 11:49, Emil Muratov wrote: >> On 05.03.2015 22:16, Alexander Motin wrote: >>> What's about the large amount of reads during UNMAP, I have two guesses: >>> 1) it may be read of metadata absent in ARC. Though I doubt that there >>> are so much metadata to read them during several minutes. >> Just to be sure I setup SSD card, made L2 ARC cache over it and set the >> vol properties to 'secondarycache=metadata'. Then run the tests again - >> acording to gstat ssd is almost idle both for reads and writes but hdds >> are still heavily loaded for reads. > L2ARC is empty on boot and filled at limited rate. You may need to read > the file several times before deleting it to make metadata get into L2ARC. Done more tests with L2ARC. Warming up L2ARC gives small improvement (if any), but the problem with IO blocking timeouts is still actual. Observing gstat behavior during IO blocks I can see that HDDs are reading something lazily at a rate about 100-200 iops for several seconds (disk queue bumps to 10, 100% busy) than for an instant comes l2ARC reads burst with 3000-4000 iops and than again many seconds of lazy hdd reads. Maybe I should dive deep into L2ARC hits and misses, but I think that there is something more than metadata reads queue, see below. Not sure if I should disable L2ARC and do clean tests or continue with caching improvement. >>> 2) if UNMAP ranges were not aligned to ZVOL block, I guess ZFS could try >>> to read blocks that need partial "unmap". I've made experiment with >>> unmapping 512 bytes of 8K ZVOL block, and it indeed zeroed specified 512 >>> bytes, from SCSI perspective while it would be fine to just ignore the >>> request. >> Maybe I should take a closer look into this. Although I've tried to do >> best to align upper layer fs to zvol blocks, I've put GPT over LUN, >> win2012 should align it to 1M boundaries, than formatted NTFS partition >> with 8K cluster. As far as I can see during heavy writes there is no >> reads at the same time from the zvol, but I will do some more tests >> investigating this point. > You should check for reads not only during writes, but also during > REwrites. If initiator actively practices UNMAP, then even misaligned > initial write may not cause read-modify-write cycle, since there is just > nothing to read. Simple large files overwrite test shows interesting results - system writes several gigs chunk of data to disks for about a minute or two, gstat shows constant large speed disk writes with a low disk queue, almost no reads - so there shouldn't be any misalign problems. Than for a very short period of time here comes that blocking behavior - writes stops, queue bumps to 10 and guest IO blocks for several seconds. Although this blocks are clearly visible but short in time and it doesn't produce guest OS timeouts. Looks like when CoW releases unused blocks from zvol those issues arises. I should repeat this test with UNMAP disabled, not sure if this is ZFS CoW or UNMAP behavior. > >> Besides this why there should be so a lot of reads at the first place? >> Isn't it enough to just update metadata to mark unmapped blocks as free? > As I can see in ZFS code, if UNMAP is not aligned to zvol blocks, then > first and last blocks are not unmapped, but instead affected parts are > written with zeroes. Those partial writes may trigger read-modify-write > cycle, if data are not already in cache. SCSI spec allows device to skip > such zero writes, and I am thinking about implementing such filtering on > CTL level. > >> And what is the most annoying is that all IO blocks for a time, I'm not >> an expert in this area but isn't there any way to reorder or delay those >> unmap op's or even drop it out if there are a lot of other pending IOs? > That was not easy to do, but CTL should be clever about this now. It > should now block only access to blocks that are affected by specific > UNMAP command. From the other side after fixing this issue on CTL level > I've noticed that in ZFS UNMAP also significantly affects performance of > other commands to the same zvol. > > To check possible CTL role in this blocking you may try to add to your > LUN configuration `option reordering unrestricted`. It makes CTL to not > track any potential request collisions. If after that UNMAP will still > block other I/Os, then all questions to ZFS. I've tried 'reordering=unrestricted' - not much of a help indeed for a single zvol. But working with two zvols simultaneously gives other results. Reading/writing/unmapping data on the same zvol blocks everything very fast. Reading/writing one zvol and unmapping files on another zvol blocks only that particular zvol where unmap is in progress. IO to the other zvol is still processed, only with a performance penalty and more bursty in nature, but at least no timeouts on the guest and tons of ctl errors in log on the target. I've made another test - attached 3rd zvol to the guest and initiated large data EXTENDED_COPY with a guest system from the 2nd zvol to the 3rd zvol. Monitoring gstat, I saw that fast speed disk reads and writes is in progress, than I started unmapping lots of large files from the first zvol. At the beginning when 1st zvol blocked completely both operations (EXTENDED_COPY and UNMAP) worked in parallel, disk queue bumped to 10, reads/writes speed decreased (but still stayed at fast-copy level). Continue pushing with more large unmaps I've reached disk queue bumped to 20-30 and then it all went to the state when all 3 zvols blocked, fast disk reads and writes stopped and disk IO went into a previously mentioned long lazy reads/short L2ARC burst reads pattern, it lasted for a minute or two until all unmaps were finished and EXTENDED_COPY continued. More and more confusion with all of this. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 16:36:44 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B363E66 for ; Sat, 14 Mar 2015 16:36:44 +0000 (UTC) Received: from thyme.infocus-llc.com (thyme.infocus-llc.com [199.15.120.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E93E069E for ; Sat, 14 Mar 2015 16:36:43 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 2026137B586 for ; Sat, 14 Mar 2015 11:36:42 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3l48fx3w3nz2jv; Sat, 14 Mar 2015 11:36:41 -0500 (CDT) Date: Sat, 14 Mar 2015 11:36:41 -0500 From: "Matthew D. Fuller" To: freebsd-fs@freebsd.org Subject: Troubles with zvol + BIO_DELETE Message-ID: <20150314163641.GK24274@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.23-fullermd.4 (2014-03-12) X-Virus-Scanned: clamav-milter 0.98.6 at thyme.infocus-llc.com X-Virus-Status: Clean X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 16:36:44 -0000 In some GELI messing, we've found some bad behavior in sending DELETE's through to a backing zvol. After investigation, my best guess is that this is actually a bug in the zvol code. The requests come into zvol_geom_start(). In "normal" cases (e.g., when doing a newfs directly on the zvol), the bio's seem to go straight through to zvol_strategy(). However, when going through GELI, we hit the !THREAD_CAN_SLEEP() case, and so they get queued up. Then zvol_geom_worker() deals with them later. However, it doesn't know anything about BIO_DELETE; there's no handling at all. So at that point, the request just hangs around pending forever. I'm pretty sure it should just get send to zvol_strategy() the same as READ/WRITE do: Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (revision 279210) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (working copy) @@ -2775,6 +2775,7 @@ break; case BIO_READ: case BIO_WRITE: + case BIO_DELETE: zvol_strategy(bp); break; } -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 17:37:25 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 907269C4 for ; Sat, 14 Mar 2015 17:37:25 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 22F97C1E for ; Sat, 14 Mar 2015 17:37:24 +0000 (UTC) Received: by wifj2 with SMTP id j2so10880841wif.1 for ; Sat, 14 Mar 2015 10:37:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P0eLQZNLN03j4UaSKf1/z22mgWFpTVnFQvtgXwIn3g8=; b=Pf8K+SOs5STkTaoOgXd0ndgyZSiSlzoEKGe71CbN21gm8yQ3HnfvQgZpn93tWrGb4d wozaTfJ/LpFwCy802ecaUZX1yfHwqicgQ6VZfGoF8K2fYXM2dznSMRjObvSAJQKbLxwG DUXaEzvUxpoITZGBmTm9sZeAi6IL8EYT/MYsl/4NiZkxT4me2lcVMABHTJQYjJmQbgTf wuwQL5YbqxWKzFRC1+oNBbvpu7pNQhYjQIn0pLldhXmKlVU8YY3VeeNrysMnY0ktIbKT lxyQWPg+2Q/rZFE1iAA2EzNbUtGMJerzgpqouIj4wip6Ez1Nlz/GzGD9un8iLm9nmag8 vc1Q== X-Gm-Message-State: ALoCoQlrQnd9yQcmxIzBSN9tbZU/6/bH/9iZffPu16g0JpRHpczl+QN+fRZf1PNeDxfxqKHpFVi3 X-Received: by 10.180.7.196 with SMTP id l4mr125542728wia.44.1426354636720; Sat, 14 Mar 2015 10:37:16 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id fo9sm7792491wib.16.2015.03.14.10.37.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2015 10:37:15 -0700 (PDT) Message-ID: <550471C3.7010409@multiplay.co.uk> Date: Sat, 14 Mar 2015 17:37:07 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Troubles with zvol + BIO_DELETE References: <20150314163641.GK24274@over-yonder.net> In-Reply-To: <20150314163641.GK24274@over-yonder.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 17:37:25 -0000 On 14/03/2015 16:36, Matthew D. Fuller wrote: > In some GELI messing, we've found some bad behavior in sending > DELETE's through to a backing zvol. After investigation, my best > guess is that this is actually a bug in the zvol code. > > The requests come into zvol_geom_start(). In "normal" cases (e.g., > when doing a newfs directly on the zvol), the bio's seem to go > straight through to zvol_strategy(). However, when going through > GELI, we hit the !THREAD_CAN_SLEEP() case, and so they get queued up. > > Then zvol_geom_worker() deals with them later. However, it doesn't > know anything about BIO_DELETE; there's no handling at all. So at > that point, the request just hangs around pending forever. I'm pretty > sure it should just get send to zvol_strategy() the same as READ/WRITE > do: > > > Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c > =================================================================== > --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (revision 279210) > +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c (working copy) > @@ -2775,6 +2775,7 @@ > break; > case BIO_READ: > case BIO_WRITE: > + case BIO_DELETE: > zvol_strategy(bp); > break; > } This is correct I've just committed the fix with a slight change so other bio types don't get lost too: https://svnweb.freebsd.org/changeset/base/279996 Its scheduled for MFC in two weeks. Thanks for this Matthew :) Regards Steve From owner-freebsd-fs@FreeBSD.ORG Sat Mar 14 22:52:33 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A8CDCDA for ; Sat, 14 Mar 2015 22:52:33 +0000 (UTC) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::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 98A3FC7F for ; Sat, 14 Mar 2015 22:52:32 +0000 (UTC) Received: by wegp1 with SMTP id p1so14370146weg.1 for ; Sat, 14 Mar 2015 15:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Vql6VPF8Fn0SegWAcQcLIDkiWcvNyPP/7dOdXFO4V0s=; b=fY1F/54B/uBlIMp2f0Pvho3UYABwmYEZxFqhqIpk1l7sv9LMUmXbYCHqt9qpr4M30x 0AlNLx5Za3OrN9a3fizYGMC/VVBZwjFU9lna7zF1jY16Mm5DB0zw76z8eGdqunKfIY1s yzFAEROZekvG63VJqwScbfsh6/GLH8CjQ7XopZJH0JFLNjIxjMQv6zM9Znr9rtgXK8Bv ryzb6IZaIKE4u/bclk5kVyw22vpJ1ZfVfpsiABw+BLKf84mhcuHpELV6HBk4HZYdE1EL kcQWbN2iNgSpQ4E847zuLyliaO6ahYmu9sIPSiDyihHlpnoHH3KDodQrc1N3bP9QwwHE RpKQ== X-Received: by 10.194.94.1 with SMTP id cy1mr106863352wjb.127.1426373550783; Sat, 14 Mar 2015 15:52:30 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id kj8sm8731310wjc.29.2015.03.14.15.52.28 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 14 Mar 2015 15:52:29 -0700 (PDT) Date: Sat, 14 Mar 2015 23:52:26 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic v_usecount and v_holdcnt Message-ID: <20150314225226.GA15302@dft-labs.eu> References: <20141122002812.GA32289@dft-labs.eu> <20141122092527.GT17068@kib.kiev.ua> <20141122211147.GA23623@dft-labs.eu> <20141124095251.GH17068@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141124095251.GH17068@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 22:52:33 -0000 On Mon, Nov 24, 2014 at 11:52:52AM +0200, Konstantin Belousov wrote: > On Sat, Nov 22, 2014 at 10:11:47PM +0100, Mateusz Guzik wrote: > > On Sat, Nov 22, 2014 at 11:25:27AM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 22, 2014 at 01:28:12AM +0100, Mateusz Guzik wrote: > > > > The idea is that we don't need an interlock as long as we don't > > > > transition either counter 1->0 or 0->1. > > > I already said that something along the lines of the patch should work. > > > In fact, you need vnode lock when hold count changes between 0 and 1, > > > and probably the same for use count. > > > > > > > I don't see why this would be required (not that I'm an VFS expert). > > vnode recycling seems to be protected with the interlock. > > > > In fact I would argue that if this is really needed, current code is > > buggy. > Yes, it is already (somewhat) buggy. > > Most need of the lock is for the case of counts coming from 1 to 0. > The reason is the handling of the active vnode list, which is used > for limiting the amount of vnode list walking in syncer. When hold > count is decremented to 0, vnode is removed from the active list. > When use count is decremented to 0, vnode is supposedly inactivated, > and vinactive() cleans the cached pages belonging to vnode. In other > words, VI_OWEINACT for dirty vnode is sort of bug. > Modified the patch to no longer have the usecount + interlock dropped + VI_OWEINACT set window. Extended 0->1 hold count + vnode not locked window remains. I can fix that if it is really necessary by having _vhold return with interlock held if it did such transition. > > > Similarly, I dislike vget_held(). Add a flag to vget(), see LK_EATTR_MASK > > > in sys/lockmgr.h. > > > Added LK_VNHELD. ========================== Rationale for this project in the first place is vnode interlock contetion. For performance considerations I did a simple test with 16 processes opening + closing files of the form /1/2/3/file${proc} for 10 seconds. I ran the test multiple times and it always got similar results. sort -nk4 | tail -10: 4 21 286087 59821 447061 0 0 0 61050 kern/subr_turnstile.c:551 (spin mutex:turnstile chain) 3 202 150391 66590 2849045 0 0 0 38808 kern/vfs_subr.c:2294 (sleep mutex:vnode interlock) 6 7 1811168 74290 8512307 0 0 0 164328 cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2126 (sx:zp->z_acl_lock) 20 25 1419986 98319 2809304 0 0 0 148656 kern/vfs_subr.c:2539 (sleep mutex:vnode interlock) 24 4 1109662 146941 14254913 0 0 0 180781 kern/subr_sleepqueue.c:251 (spin mutex:sleepq chain) 480 39 92451121 996583 5674822 16 0 0 191116 kern/vfs_subr.c:2176 (lockmgr:zfs) 5 386 630453 8320678 5675428 0 1 0 487331 kern/vfs_subr.c:2184 (sleep mutex:vnode interlock) 8 440 3171462 9687352 5675274 0 1 0 800833 kern/vfs_cache.c:668 (sleep mutex:vnode interlock) 8 381 1908209 41077673 2838476 0 14 0 1943683 kern/vfs_subr.c:2211 (sleep mutex:vnode interlock) 16 380 4401208 52113492 8513892 0 6 0 2630199 kern/vfs_subr.c:2254 (sleep mutex:vnode interlock) In comparison with atomic counters: 4 3 417431 14942 2503166 0 0 0 29277 cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1373 (sx:arc_mfu->arcs_locks[i].arcs_lock) 4 8 355527 41360 5125918 0 0 0 47753 kern/vfs_subr.c:2300 (sleep mutex:vnode interlock) 6 10 7486379 993366 31423111 0 0 0 1644513 cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c:223 (sx:rrl->rr_lock) 5 42 3122209 1591643 31423107 0 0 0 2369782 cddl/contrib/opensolaris/uts/common/fs/zfs/rrwlock.c:165 (sx:rrl->rr_lock) 6 107 799818 2095611 3491446 0 0 0 1322296 kern/vfs_subr.c:2383 (sleep mutex:vnode_free_list) 5 95 709042 2400191 3491446 0 0 0 1346013 kern/vfs_subr.c:2441 (sleep mutex:vnode_free_list) 27 51 3727414 3382053 29383205 0 0 0 1066198 kern/subr_sleepqueue.c:251 (spin mutex:sleepq chain) 4 44 809608 4020811 5837543 0 0 0 1115968 kern/vfs_subr.c:2190 (sleep mutex:vnode interlock) 136 119 85703294 8917689 13965774 6 0 0 1215102 kern/vfs_subr.c:2169 (lockmgr:zfs) 13 112 7178437 17880353 20948741 0 0 0 5322368 cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2126 (sx:zp->z_acl_lock) ops/s were ~140k with the interlock and ~345k with atomics. With such a big (repeatble) difference I did not consider making enough runs to make ministat happy. ========================== Patch below would use some tidy ups, but I consider it correct from semantic pov. For convenience it contains refcount bits which are about to be reviewed in another thread. Indeed *_if_greater funcs should likely be converted to just deal with zero and non-zero count, but that does not change the outcome. diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c b/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c index 83f29c1..b587ebd 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c @@ -99,6 +99,6 @@ vn_rele_async(vnode_t *vp, taskq_t *taskq) (task_func_t *)vn_rele_inactive, vp, TQ_SLEEP) != 0); return; } - vp->v_usecount--; + refcount_release(&vp->v_usecount); vdropl(vp); } diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index d57dc90..f3f8339 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -665,12 +665,12 @@ success: ltype = VOP_ISLOCKED(dvp); VOP_UNLOCK(dvp, 0); } - VI_LOCK(*vpp); + vhold(*vpp); if (wlocked) CACHE_WUNLOCK(); else CACHE_RUNLOCK(); - error = vget(*vpp, cnp->cn_lkflags | LK_INTERLOCK, cnp->cn_thread); + error = vget(*vpp, cnp->cn_lkflags | LK_VNHELD, cnp->cn_thread); if (cnp->cn_flags & ISDOTDOT) { vn_lock(dvp, ltype | LK_RETRY); if (dvp->v_iflag & VI_DOOMED) { @@ -1368,9 +1368,9 @@ vn_dir_dd_ino(struct vnode *vp) if ((ncp->nc_flag & NCF_ISDOTDOT) != 0) continue; ddvp = ncp->nc_dvp; - VI_LOCK(ddvp); + vhold(ddvp); CACHE_RUNLOCK(); - if (vget(ddvp, LK_INTERLOCK | LK_SHARED | LK_NOWAIT, curthread)) + if (vget(ddvp, LK_SHARED | LK_NOWAIT | LK_VNHELD, curthread)) return (NULL); return (ddvp); } diff --git a/sys/kern/vfs_hash.c b/sys/kern/vfs_hash.c index 930fca1..48601e7 100644 --- a/sys/kern/vfs_hash.c +++ b/sys/kern/vfs_hash.c @@ -84,9 +84,9 @@ vfs_hash_get(const struct mount *mp, u_int hash, int flags, struct thread *td, s continue; if (fn != NULL && fn(vp, arg)) continue; - VI_LOCK(vp); + vhold(vp); rw_runlock(&vfs_hash_lock); - error = vget(vp, flags | LK_INTERLOCK, td); + error = vget(vp, flags | LK_VNHELD, td); if (error == ENOENT && (flags & LK_NOWAIT) == 0) break; if (error) @@ -128,9 +128,9 @@ vfs_hash_insert(struct vnode *vp, u_int hash, int flags, struct thread *td, stru continue; if (fn != NULL && fn(vp2, arg)) continue; - VI_LOCK(vp2); + vhold(vp2); rw_wunlock(&vfs_hash_lock); - error = vget(vp2, flags | LK_INTERLOCK, td); + error = vget(vp2, flags | LK_VNHELD, td); if (error == ENOENT && (flags & LK_NOWAIT) == 0) break; rw_wlock(&vfs_hash_lock); diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index fda80c9..85ff203 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -102,9 +103,9 @@ static int flushbuflist(struct bufv *bufv, int flags, struct bufobj *bo, static void syncer_shutdown(void *arg, int howto); static int vtryrecycle(struct vnode *vp); static void v_incr_usecount(struct vnode *); -static void v_decr_usecount(struct vnode *); -static void v_decr_useonly(struct vnode *); static void v_upgrade_usecount(struct vnode *); +static void v_incr_devcount(struct vnode *); +static void v_decr_devcount(struct vnode *); static void vnlru_free(int); static void vgonel(struct vnode *); static void vfs_knllock(void *arg); @@ -863,7 +864,7 @@ vnlru_free(int count) */ freevnodes--; vp->v_iflag &= ~VI_FREE; - vp->v_holdcnt++; + refcount_acquire(&vp->v_holdcnt); mtx_unlock(&vnode_free_list_mtx); VI_UNLOCK(vp); @@ -2082,70 +2083,50 @@ static void v_incr_usecount(struct vnode *vp) { + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vholdl(vp); - vp->v_usecount++; - if (vp->v_type == VCHR && vp->v_rdev != NULL) { - dev_lock(); - vp->v_rdev->si_usecount++; - dev_unlock(); - } + vhold(vp); + v_upgrade_usecount(vp); } /* - * Turn a holdcnt into a use+holdcnt such that only one call to - * v_decr_usecount is needed. + * Turn a holdcnt into a use+holdcnt. */ static void v_upgrade_usecount(struct vnode *vp) { + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount++; - if (vp->v_type == VCHR && vp->v_rdev != NULL) { - dev_lock(); - vp->v_rdev->si_usecount++; - dev_unlock(); + if (!refcount_acquire_if_greater(&vp->v_usecount, 0)) { + VI_LOCK(vp); + refcount_acquire(&vp->v_usecount); + VI_UNLOCK(vp); } + v_incr_devcount(vp); } /* - * Decrement the vnode use and hold count along with the driver's usecount - * if this is a chardev. The vdropl() below releases the vnode interlock - * as it may free the vnode. + * Increment si_usecount of the associated device, if any. */ static void -v_decr_usecount(struct vnode *vp) +v_incr_devcount(struct vnode *vp) { - ASSERT_VI_LOCKED(vp, __FUNCTION__); - VNASSERT(vp->v_usecount > 0, vp, - ("v_decr_usecount: negative usecount")); - CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount--; if (vp->v_type == VCHR && vp->v_rdev != NULL) { dev_lock(); - vp->v_rdev->si_usecount--; + vp->v_rdev->si_usecount++; dev_unlock(); } - vdropl(vp); } /* - * Decrement only the use count and driver use count. This is intended to - * be paired with a follow on vdropl() to release the remaining hold count. - * In this way we may vgone() a vnode with a 0 usecount without risk of - * having it end up on a free list because the hold count is kept above 0. + * Increment si_usecount of the associated device, if any. */ static void -v_decr_useonly(struct vnode *vp) +v_decr_devcount(struct vnode *vp) { - ASSERT_VI_LOCKED(vp, __FUNCTION__); - VNASSERT(vp->v_usecount > 0, vp, - ("v_decr_useonly: negative usecount")); - CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount--; if (vp->v_type == VCHR && vp->v_rdev != NULL) { dev_lock(); vp->v_rdev->si_usecount--; @@ -2163,17 +2144,29 @@ v_decr_useonly(struct vnode *vp) int vget(struct vnode *vp, int flags, struct thread *td) { - int error; + int error, oweinact; - error = 0; VNASSERT((flags & LK_TYPE_MASK) != 0, vp, ("vget: invalid lock operation")); + + ASSERT_VI_LOCK(vp, __func__, (flags & LK_INTERLOCK) != 0); + if ((flags & LK_VNHELD) != 0) + VNASSERT((vp->v_holdcnt > 0), vp, + ("vget: LK_VNHELD passed but vnode not held")); +#if 0 + else { + ASSERT_VI_LOCKED(vp, __func__); + KASSERT((flags & LK_INTERLOCK) != 0, + ("vget: neither LK_INTERLOCK nor LK_VNHELD passed")); + } +#endif + CTR3(KTR_VFS, "%s: vp %p with flags %d", __func__, vp, flags); - if ((flags & LK_INTERLOCK) == 0) - VI_LOCK(vp); - vholdl(vp); - if ((error = vn_lock(vp, flags | LK_INTERLOCK)) != 0) { + if ((flags & LK_VNHELD) == 0) + _vhold(vp, (flags & LK_INTERLOCK) != 0); + + if ((error = vn_lock(vp, flags)) != 0) { vdrop(vp); CTR2(KTR_VFS, "%s: impossible to lock vnode %p", __func__, vp); @@ -2181,22 +2174,33 @@ vget(struct vnode *vp, int flags, struct thread *td) } if (vp->v_iflag & VI_DOOMED && (flags & LK_RETRY) == 0) panic("vget: vn_lock failed to return ENOENT\n"); - VI_LOCK(vp); - /* Upgrade our holdcnt to a usecount. */ - v_upgrade_usecount(vp); /* * We don't guarantee that any particular close will * trigger inactive processing so just make a best effort * here at preventing a reference to a removed file. If * we don't succeed no harm is done. + * + * Upgrade our holdcnt to a usecount. */ - if (vp->v_iflag & VI_OWEINACT) { - if (VOP_ISLOCKED(vp) == LK_EXCLUSIVE && + if (refcount_acquire_if_greater(&vp->v_usecount, 0)) { + v_incr_devcount(vp); + VNASSERT((vp->v_iflag & VI_OWEINACT) == 0, vp, + ("vget: vnode with VI_OWEINACT and usecount")); + } else { + VI_LOCK(vp); + if ((vp->v_iflag & VI_OWEINACT) == 0) { + oweinact = 0; + } else { + oweinact = 1; + vp->v_iflag &= ~VI_OWEINACT; + } + refcount_acquire(&vp->v_usecount); + v_incr_devcount(vp); + if (oweinact && VOP_ISLOCKED(vp) == LK_EXCLUSIVE && (flags & LK_NOWAIT) == 0) vinactive(vp, td); - vp->v_iflag &= ~VI_OWEINACT; + VI_UNLOCK(vp); } - VI_UNLOCK(vp); return (0); } @@ -2208,9 +2212,7 @@ vref(struct vnode *vp) { CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - VI_LOCK(vp); v_incr_usecount(vp); - VI_UNLOCK(vp); } /* @@ -2225,13 +2227,8 @@ vref(struct vnode *vp) int vrefcnt(struct vnode *vp) { - int usecnt; - - VI_LOCK(vp); - usecnt = vp->v_usecount; - VI_UNLOCK(vp); - return (usecnt); + return (vp->v_usecount); } #define VPUTX_VRELE 1 @@ -2250,33 +2247,42 @@ vputx(struct vnode *vp, int func) ASSERT_VOP_LOCKED(vp, "vput"); else KASSERT(func == VPUTX_VRELE, ("vputx: wrong func")); + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - VI_LOCK(vp); - - /* Skip this v_writecount check if we're going to panic below. */ - VNASSERT(vp->v_writecount < vp->v_usecount || vp->v_usecount < 1, vp, - ("vputx: missed vn_close")); - error = 0; - if (vp->v_usecount > 1 || ((vp->v_iflag & VI_DOINGINACT) && - vp->v_usecount == 1)) { + if (refcount_release_if_greater(&vp->v_usecount, 1)) { if (func == VPUTX_VPUT) VOP_UNLOCK(vp, 0); - v_decr_usecount(vp); + v_decr_devcount(vp); + vdrop(vp); return; } - if (vp->v_usecount != 1) { - vprint("vputx: negative ref count", vp); - panic("vputx: negative ref cnt"); - } - CTR2(KTR_VFS, "%s: return vnode %p to the freelist", __func__, vp); + VI_LOCK(vp); + /* * We want to hold the vnode until the inactive finishes to * prevent vgone() races. We drop the use count here and the * hold count below when we're done. */ - v_decr_useonly(vp); + if (!refcount_release(&vp->v_usecount) || (vp->v_iflag & VI_DOINGINACT)) { + if (func == VPUTX_VPUT) + VOP_UNLOCK(vp, 0); + v_decr_devcount(vp); + vdropl(vp); + return; + } + + v_decr_devcount(vp); + + error = 0; + + if (vp->v_usecount != 0) { + vprint("vputx: negative ref count", vp); + panic("vputx: negative ref cnt"); + } + CTR2(KTR_VFS, "%s: return vnode %p to the freelist", __func__, vp); + /* * We must call VOP_INACTIVE with the node locked. Mark * as VI_DOINGINACT to avoid recursion. @@ -2346,38 +2352,29 @@ vunref(struct vnode *vp) } /* - * Somebody doesn't want the vnode recycled. - */ -void -vhold(struct vnode *vp) -{ - - VI_LOCK(vp); - vholdl(vp); - VI_UNLOCK(vp); -} - -/* * Increase the hold count and activate if this is the first reference. */ void -vholdl(struct vnode *vp) +_vhold(struct vnode *vp, bool locked) { struct mount *mp; + ASSERT_VI_LOCK(vp, __func__, locked); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); -#ifdef INVARIANTS - /* getnewvnode() calls v_incr_usecount() without holding interlock. */ - if (vp->v_type != VNON || vp->v_data != NULL) { - ASSERT_VI_LOCKED(vp, "vholdl"); - VNASSERT(vp->v_holdcnt > 0 || (vp->v_iflag & VI_FREE) != 0, - vp, ("vholdl: free vnode is held")); + if (refcount_acquire_if_greater(&vp->v_holdcnt, 0)) { + VNASSERT((vp->v_iflag & VI_FREE) == 0, vp, + ("_vhold: vnode with holdcnt is free")); + return; } -#endif - vp->v_holdcnt++; - if ((vp->v_iflag & VI_FREE) == 0) + if (!locked) + VI_LOCK(vp); + if ((vp->v_iflag & VI_FREE) == 0) { + refcount_acquire(&vp->v_holdcnt); + if (!locked) + VI_UNLOCK(vp); return; - VNASSERT(vp->v_holdcnt == 1, vp, ("vholdl: wrong hold count")); + } + VNASSERT(vp->v_holdcnt == 0, vp, ("vholdl: wrong hold count")); VNASSERT(vp->v_op != NULL, vp, ("vholdl: vnode already reclaimed.")); /* * Remove a vnode from the free list, mark it as in use, @@ -2394,18 +2391,9 @@ vholdl(struct vnode *vp) TAILQ_INSERT_HEAD(&mp->mnt_activevnodelist, vp, v_actfreelist); mp->mnt_activevnodelistsize++; mtx_unlock(&vnode_free_list_mtx); -} - -/* - * Note that there is one less who cares about this vnode. - * vdrop() is the opposite of vhold(). - */ -void -vdrop(struct vnode *vp) -{ - - VI_LOCK(vp); - vdropl(vp); + refcount_acquire(&vp->v_holdcnt); + if (!locked) + VI_UNLOCK(vp); } /* @@ -2414,20 +2402,25 @@ vdrop(struct vnode *vp) * (marked VI_DOOMED) in which case we will free it. */ void -vdropl(struct vnode *vp) +_vdrop(struct vnode *vp, bool locked) { struct bufobj *bo; struct mount *mp; int active; - ASSERT_VI_LOCKED(vp, "vdropl"); + ASSERT_VI_LOCK(vp, __func__, locked); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); if (vp->v_holdcnt <= 0) panic("vdrop: holdcnt %d", vp->v_holdcnt); - vp->v_holdcnt--; - VNASSERT(vp->v_holdcnt >= vp->v_usecount, vp, - ("hold count less than use count")); - if (vp->v_holdcnt > 0) { + if (refcount_release_if_greater(&vp->v_holdcnt, 1)) { + if (locked) + VI_UNLOCK(vp); + return; + } + + if (!locked) + VI_LOCK(vp); + if (refcount_release(&vp->v_holdcnt) == 0) { VI_UNLOCK(vp); return; } diff --git a/sys/sys/lockmgr.h b/sys/sys/lockmgr.h index ff0473d..a74d5f5 100644 --- a/sys/sys/lockmgr.h +++ b/sys/sys/lockmgr.h @@ -159,6 +159,7 @@ _lockmgr_args_rw(struct lock *lk, u_int flags, struct rwlock *ilk, #define LK_SLEEPFAIL 0x000800 #define LK_TIMELOCK 0x001000 #define LK_NODDLKTREAT 0x002000 +#define LK_VNHELD 0x004000 /* * Operations for lockmgr(). diff --git a/sys/sys/refcount.h b/sys/sys/refcount.h index 4611664..b6ddb90 100644 --- a/sys/sys/refcount.h +++ b/sys/sys/refcount.h @@ -64,4 +64,64 @@ refcount_release(volatile u_int *count) return (old == 1); } +static __inline int +refcount_acquire_if_greater(volatile u_int *count, int val) +{ + int old; + + for (;;) { + old = *count; + if (old <= val) + return (0); + if (atomic_cmpset_int(count, old, old + 1)) + return (1); + } +} + +static __inline int +refcount_release_if_greater(volatile u_int *count, int val) +{ + int old; + + for (;;) { + old = *count; + if (old <= val) + return (0); + if (atomic_cmpset_int(count, old, old - 1)) + return (1); + } +} + +#define _refcount_release_lock(count, lock, TYPE, LOCK_OP, UNLOCK_OP) \ +({ \ + TYPE *__lock; \ + volatile u_int *__cp; \ + int __ret; \ + \ + __lock = (lock); \ + __cp = (count); \ + \ + if (refcount_release_if_greater(__cp, 1)) { \ + __ret = 0; \ + } else { \ + LOCK_OP(__lock); \ + if (refcount_release(__cp)) { \ + __ret = 1; \ + } else { \ + UNLOCK_OP(__lock); \ + __ret = 0; \ + } \ + } \ + __ret; \ +}) + +#define refcount_release_lock_mtx(count, lock) \ + _refcount_release_lock(count, lock, struct mtx, mtx_lock, mtx_unlock) +#define refcount_release_lock_rmlock(count, lock) \ + _refcount_release_lock(count, lock, struct rmlock, rm_wlock, rm_wunlock) +#define refcount_release_lock_rwlock(count, lock) \ + _refcount_release_lock(count, lock, struct rwlock, rw_wlock, rw_wunlock) +#define refcount_release_lock_sx(count, lock) \ + _refcount_release_lock(count, lock, struct sx, sx_xlock, sx_xunlock) + #endif /* ! __SYS_REFCOUNT_H__ */ diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index e1f912e..c695b52 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -547,6 +547,15 @@ void assert_vop_unlocked(struct vnode *vp, const char *str); #define ASSERT_VOP_UNLOCKED(vp, str) ((void)0) #endif /* DEBUG_VFS_LOCKS */ +static __inline void +ASSERT_VI_LOCK(struct vnode *vp, const char *str, bool locked) +{ + + if (locked) + ASSERT_VI_LOCKED(vp, str); + else + ASSERT_VI_UNLOCKED(vp, str); +} /* * This call works for vnodes in the kernel. @@ -649,13 +658,15 @@ int vaccess_acl_posix1e(enum vtype type, uid_t file_uid, struct ucred *cred, int *privused); void vattr_null(struct vattr *vap); int vcount(struct vnode *vp); -void vdrop(struct vnode *); -void vdropl(struct vnode *); +#define vdrop(vp) _vdrop((vp), 0) +#define vdropl(vp) _vdrop((vp), 1) +void _vdrop(struct vnode *, bool); int vflush(struct mount *mp, int rootrefs, int flags, struct thread *td); int vget(struct vnode *vp, int lockflag, struct thread *td); void vgone(struct vnode *vp); -void vhold(struct vnode *); -void vholdl(struct vnode *); +#define vhold(vp) _vhold((vp), 0) +#define vholdl(vp) _vhold((vp), 1) +void _vhold(struct vnode *, bool); void vinactive(struct vnode *, struct thread *); int vinvalbuf(struct vnode *vp, int save, int slpflag, int slptimeo); int vtruncbuf(struct vnode *vp, struct ucred *cred, off_t length, -- Mateusz Guzik