From owner-freebsd-fs@freebsd.org Sun Jun 9 21:01:04 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEA5515AB5D9 for ; Sun, 9 Jun 2019 21:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBF786687 for ; Sun, 9 Jun 2019 21:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id DACF015AB5CF; Sun, 9 Jun 2019 21:01:03 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6E4815AB5CE for ; Sun, 9 Jun 2019 21:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 382F486681 for ; Sun, 9 Jun 2019 21:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5F111254E for ; Sun, 9 Jun 2019 21:01:02 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x59L12Ii008349 for ; Sun, 9 Jun 2019 21:01:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x59L12dQ008348 for fs@FreeBSD.org; Sun, 9 Jun 2019 21:01:02 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201906092101.x59L12dQ008348@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention Date: Sun, 9 Jun 2019 21:01:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 21:01:05 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS Open | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 235665 | panic: handle_written_inodeblock: live inodedep Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w 6 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Sun Jun 9 21:40:34 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DD3B15ACB7E for ; Sun, 9 Jun 2019 21:40:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BC0C587CBE for ; Sun, 9 Jun 2019 21:40:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 75E4D15ACB7D; Sun, 9 Jun 2019 21:40:33 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 367F915ACB7C for ; Sun, 9 Jun 2019 21:40:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670044.outbound.protection.outlook.com [40.107.67.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C249787CB0 for ; Sun, 9 Jun 2019 21:40:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM (52.132.93.160) by YQXPR01MB2952.CANPRD01.PROD.OUTLOOK.COM (52.132.93.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.14; Sun, 9 Jun 2019 21:40:27 +0000 Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::f9fe:559f:fdc:9e5a]) by YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::f9fe:559f:fdc:9e5a%3]) with mapi id 15.20.1965.017; Sun, 9 Jun 2019 21:40:27 +0000 From: Rick Macklem To: "fs@FreeBSD.org" Subject: Re: Problem reports for fs@FreeBSD.org that need special attention Thread-Topic: Problem reports for fs@FreeBSD.org that need special attention Thread-Index: AQHVHwZ+6U1sIkdR20GRPK0YX7nK06aT2Wpo Date: Sun, 9 Jun 2019 21:40:27 +0000 Message-ID: References: <201906092101.x59L12dQ008348@kenobi.freebsd.org> In-Reply-To: <201906092101.x59L12dQ008348@kenobi.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b7dd63f-7eb6-4c66-ea82-08d6ed231686 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YQXPR01MB2952; x-ms-traffictypediagnostic: YQXPR01MB2952: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 006339698F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39850400004)(396003)(376002)(136003)(199004)(189003)(486006)(66946007)(305945005)(73956011)(66446008)(64756008)(66556008)(66476007)(786003)(316002)(46003)(99286004)(11346002)(446003)(6916009)(76116006)(5660300002)(86362001)(68736007)(186003)(52536014)(476003)(8676002)(81166006)(1730700003)(2906002)(81156014)(8936002)(6506007)(53546011)(7696005)(256004)(71200400001)(222073003)(53936002)(966005)(6436002)(9686003)(102836004)(76176011)(71190400001)(478600001)(74316002)(33656002)(2351001)(2501003)(55016002)(25786009)(6306002)(6246003)(5640700003)(14454004)(74482002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR01MB2952; H:YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +S4VrLugp1HB71urSHFfF258RB/nI8TvWVHrNwOmWPcjRAR5z+F2AXACrb5Qw+V1SB8h9Tt1k0nCJSwTn9TgvCBRLCCWQZ5yqZBPEyUcVkvGoWelcxiFKCZzGBkfv21bFSynTFCtxur2rKkWPCE6HE8s/Kdc+RCtFk8kxr0r/Kc+mkZzmGOGU7bsPmolF56I5fDZHmyIl0H9fK7P/R4ZJg7ejtfXuogBSdJVec21yQ/sdx9t6SCzRCyZkIJLadJ2YpQq6rAd5Xy25nFmgfhNbioGjDq6Yx2n/3lVbTcXJHSbQZ3Ar1XBUU9CVbLbp+cackFPvhiTVGX04lmcao3409vU9vgbq5CwZApNkpQSOvhlaLf6wrGagk7oO64ukbeGA8/zGQIjvlOWoHjpy37XD0ZMEP6GcFkejtXWsHIr1CQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 8b7dd63f-7eb6-4c66-ea82-08d6ed231686 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2019 21:40:27.6013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2952 X-Rspamd-Queue-Id: C249787CB0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 21:40:34 -0000 I don't know how this list gets generated, but I think PR#147881 should be on it. I recently tried an email to stimulate activity w.r.t. this PR, but nothing= has happened yet. I think it is assigned to freebsd-fs@. rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of bugzilla-noreply@FreeBSD.org Sent: Sunday, June 9, 2019 5:01 PM To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------= - New | 203492 | mount_unionfs -o below causes panic Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 211491 | System hangs after "Uptime" on reboot with ZFS Open | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 235665 | panic: handle_written_inodeblock: live inodedep Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w 6 problems total for which you should take action. _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@freebsd.org Mon Jun 10 16:25:10 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A035815C3636 for ; Mon, 10 Jun 2019 16:25:10 +0000 (UTC) (envelope-from clara.alexis@globaltechnointernational.com) Received: from n1nlsmtp01.shr.prod.ams1.secureserver.net (n1nlsmtp01.shr.prod.ams1.secureserver.net [188.121.43.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay-hosting.secureserver.net", Issuer "Starfield Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2E0582476 for ; Mon, 10 Jun 2019 16:25:09 +0000 (UTC) (envelope-from clara.alexis@globaltechnointernational.com) Received: from n3plcpnl0291.prod.ams3.secureserver.net ([160.153.156.41]) by : HOSTING RELAY : with ESMTP id aMnEhYCzG7E3daMnEh4BIb; Mon, 10 Jun 2019 09:05:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=globaltechnointernational.com; s=default; h=Content-Type:MIME-Version: Message-ID:Date:Subject:To:From:Reply-To:Sender:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1gNhDDqiB9CNP6JR0EmUqMNw/77EcqsmmYNkjFE0ixc=; b=BjMHOT4pD7MZHvlPz14QGujuL gY5yUaRON/sFwUTJL3Sbzsg+UWCz6UBHGbpiB4QH+zP0D9hIAdgvbUdecAyvqvIIjRVhWZjCnL/XY eUlJpZywyuXqEfMTSVgeYAI6L3GCwRwl3l4sErwZY11Px8hNPD3MH5AY8Dez81GnGw952n8rmD9Tk o9PpZnwTP3Q2+Ai3FNzG4rOUGUactFgW5UN5yqlKNRjZzjB29fbK91oG5aBC81S0T6LZtTpz1Mho+ 8ryUtm2fKgN7jWvXwyphQnI0Vp3rIWalVneSvPuxwr5a+YK64EpQvtdtVoHXMiqtdRjPXWTsGpNXB qJxBuAGLQ==; Received: from [207.244.100.148] (port=50312 helo=WS41) by n3plcpnl0291.prod.ams3.secureserver.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.92) (envelope-from ) id 1haMnD-008tIP-PH for freebsd-fs@freebsd.org; Mon, 10 Jun 2019 09:05:08 -0700 Reply-To: From: "Clara Alexis" To: Subject: IBM Potential Business Lead Date: Mon, 10 Jun 2019 21:34:14 +0530 Message-ID: <0aba01d51fa6$462faf20$d28f0d60$@globaltechnointernational.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdUfpiFeLcVLZjVdQw6rvVu9Cv/cUw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - n3plcpnl0291.prod.ams3.secureserver.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - globaltechnointernational.com X-Get-Message-Sender-Via: n3plcpnl0291.prod.ams3.secureserver.net: authenticated_id: clara.alexis@globaltechnointernational.com X-Authenticated-Sender: n3plcpnl0291.prod.ams3.secureserver.net: clara.alexis@globaltechnointernational.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfHqBC2pENJCLYBpcA/zR7d42w4OMDA/vMRlzLTXZDk+O6DsfExwqLGIA97T+2SjaNpMlihe3rPYfizAr+rqm0VyBqtG5GWavDym9KXBL+0Xar5pJ8BLO Kom5P6KnyxuiyIcT1Kmf4PNykkzn2ef+awv3kjn61LmLawlxIQDAPGK8hgkJn1wzHWcSmtJNlZiUY1ia5eWRQE8lECNP+WMvtUPdihbTQcCy2OrY3jgck772 CMVgrvNPuw0jziUhKlvEdg== X-Rspamd-Queue-Id: B2E0582476 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=globaltechnointernational.com header.s=default header.b=BjMHOT4p X-Spamd-Result: default: False [1.46 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[clara.alexis@globaltechnointernational.com]; MX_INVALID(0.50)[cached]; HAS_X_SOURCE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[globaltechnointernational.com:~]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(0.27)[ip: (0.70), ipnet: 188.121.40.0/22(0.50), asn: 26496(0.21), country: US(-0.06)]; ASN(0.00)[asn:26496, ipnet:188.121.40.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[clara.alexis@globaltechnointernational.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.38)[0.384,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[globaltechnointernational.com]; NEURAL_SPAM_MEDIUM(0.25)[0.251,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.16)[0.156,0]; RCVD_IN_DNSWL_NONE(0.00)[201.43.121.188.list.dnswl.org : 127.0.5.0]; R_DKIM_PERMFAIL(0.00)[globaltechnointernational.com:s=default]; R_SPF_NA(0.00)[]; HAS_X_GMSV(0.00)[clara.alexis@globaltechnointernational.com]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 16:25:11 -0000 Hi there, I'm curious to know if you would be interested in purchasing IBM Users Lists for your sales and marketing campaigns? Some few users you might be interested in: Informatica, NetSuite, Sage CRM, Microsoft Dynamics, Oracle and SAP etc. Note: I could provide Any Industry, any Job title of users/contact lists as per your requirements. Help me out your Target Geography: ________________ Let me know if you are interested and I will get back to you with more information, Counts and pricing for your review. Regards, Clara Alexis Manager-Demand Generation If you are not interested in receiving our mails kindly reply in subject line leave out or remove. From owner-freebsd-fs@freebsd.org Tue Jun 11 06:12:53 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15BE415AEFDC for ; Tue, 11 Jun 2019 06:12:53 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A253475E27 for ; Tue, 11 Jun 2019 06:12:51 +0000 (UTC) (envelope-from stilezy@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id n4so11533020wrs.3 for ; Mon, 10 Jun 2019 23:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:date:message-id:user-agent:subject:mime-version; bh=0+CTgm19VAV9c5WHHPGIJ3NW4WZVDOaqggbv8ZMHmw0=; b=b+44y7LtCcqSaYg2NEbBEi1VrATae7VMoyfQxuNWefkO5TCjoPFDYa0F5qb3uwGXAr xYmNQsNOF8CQXI6YvKdt8rkZ0gKdebBQkk8qVs8DIuAp60rm9VvjLNCOnzTpyp/QO/ZF eonmAgBpVqKNRwbHZsKKzMYoXs5mjeQLcs7IQq2QHMV4aBgwmYdoppolKWFZLNUKcdjr IU8ZGZiqw9W/KAOpTRQHXT1BPBU/9G1GS8KNHlpKyr9Y6akLSFGO1sKhf89hlKlLHKqk nb+WU4fT1s45m4XYMKb5HztKteOtFulrl/Bj0HlUp5shwJH49EEh9GSZVuzXdJ+ko9q4 IeCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:date:message-id:user-agent:subject :mime-version; bh=0+CTgm19VAV9c5WHHPGIJ3NW4WZVDOaqggbv8ZMHmw0=; b=ohjRRSKRThjRhEzG5joBfi2UzbHpiUrav6hFLkoTYDbBBk4YtxMdFq1GnZKvFQCQy/ OqcDCQTkKNQH5JjCFmhooyZMPsXAp6stDfOWfFOOb0UY89qLfjhdXBLk7swgWZI4y56c tyytTzv8WQUJhw+jgNRy61hss21HND52xihdAcznigh7JNTkNCvlzZJuUElr/vRCMi6c l81ZJUVPxzde0j15jZx2mllR2bFlq/gJXBA9PV4302sOYWSZavMi5MzvMUejDsQxw+nv zR6Ch8HZH5EZaJd3nsOs6mY4vJ/C6jmRVQWm8ScvVvfzF6ujEhUn/y30mtMv+OC4qaJA f7TQ== X-Gm-Message-State: APjAAAVfuuCHOw2/KqLV+nR8VX+aUmJvfrcq7o+q0XGorYsx+8Q0AwUj HO0TGM2uG8GNK5hwOgkiAADHFhBM X-Google-Smtp-Source: APXvYqxwuzHWrRmc5az0p5SAablyvMRfdxj6R6vZYFeJiIVUaUcVmYKYlrafKKajrgHPM6jYkt4eGw== X-Received: by 2002:adf:8bdd:: with SMTP id w29mr20599215wra.325.1560233568898; Mon, 10 Jun 2019 23:12:48 -0700 (PDT) Received: from [10.193.100.21] ([78.32.235.97]) by smtp.gmail.com with ESMTPSA id h90sm29066776wrh.15.2019.06.10.23.12.48 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Jun 2019 23:12:48 -0700 (PDT) From: Stilez To: Date: Tue, 11 Jun 2019 07:12:47 +0100 Message-ID: <16b452ae318.2783.49a377fccbf53440a4b582c142a1ed88@gmail.com> User-Agent: AquaMail/1.19.0-1434 (build: 101900002) Subject: [ZFS] Interaction between DDT R/W and ashift/block size? MIME-Version: 1.0 X-Rspamd-Queue-Id: A253475E27 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=b+44y7Lt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of stilezy@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=stilezy@gmail.com X-Spamd-Result: default: False [-5.83 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.97)[-0.975,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.85)[ip: (-9.52), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-2.29), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; SUBJECT_ENDS_QUESTION(1.00)[] Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 06:12:53 -0000 Can someone please clarify for me, how DDT block R/W is affected by the ashift setting and pool block sizes, as this is fairly deep ZFS stuff. Thanks 1) DDT entries are typically 180-280 bytes on disk. A look at gstat or other disk tools (iostat, dtrace) shows that DDT blocks are typically 4K on disk, on a usual system with ashift=12. - Does this mean that a typical on-disk 4K DDT block will usually contain ~ 10-20 DDT entries? Or do on-disk DDT blocks only store 1 entry per block, regardless of block size, wasting most of their space? 2) Like other blocks, DDT are collated in TXGs before writing out, suggesting they might be written sequentially, in groups, or with multiple entries per block, making larger IO more efficient. - If I increase ashift from 12 to say 13 or 14, is this likely to enhance DDT storage efficiency and DDT record load/save time by cutting IO, or just waste space with no DDT IO benefit? (I appreciate this would impact small files in the pool). What about increasing prefetch for small IO? Both pool and server are specced for and suitable for dedup, being ~ 4x dedup and having ~ 0.25 TB ARC + 0.5 TB of 900p L2ARC, with a metadata reservation in ARC ample for the entire 162M entries in DDT as well as all other metadata. I'm also assuming ashift size applies to DDT blocks in the first place. Thanks for any insight available, as this is fairly deep stuff in the ZFS codebase. Stilez From owner-freebsd-fs@freebsd.org Tue Jun 11 15:09:24 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03B3615BDDEB for ; Tue, 11 Jun 2019 15:09:24 +0000 (UTC) (envelope-from possible@perfumefraud.icu) Received: from perfumefraud.icu (jkjx55ll.ni.net.tr [89.252.163.165]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE5469AA8 for ; Tue, 11 Jun 2019 15:09:22 +0000 (UTC) (envelope-from possible@perfumefraud.icu) From: " Dallas" Date: Tue, 11 Jun 2019 09:47:18 -0500 MIME-Version: 1.0 Subject: 4K Drone for $99 To: Message-ID: X-Rspamd-Queue-Id: 1CE5469AA8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.16 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[perfumefraud.icu:s=mail]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:89.252.163.165]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; SUBJECT_HAS_CURRENCY(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DKIM_TRACE(0.00)[perfumefraud.icu:+]; DMARC_POLICY_ALLOW(-0.50)[perfumefraud.icu,quarantine]; MX_GOOD(-0.01)[cached: aspmx.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-1.17)[ip: (-8.54), ipnet: 89.252.163.0/24(0.88), asn: 51559(1.78), country: TR(0.05)]; ASN(0.00)[asn:51559, ipnet:89.252.163.0/24, country:TR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 15:09:24 -0000 View larger View larger View larger View larger A marvel of engineering and design Mavic Air was built to go wherever adventure takes you. Inheriting the best of the Mavic series, this ultraportable and foldable drone features high-end flight performance and functionality for limitless exploration 3-Axis Gimbal Camera The Mavic Air is the most portable DJI drone to house a 3-axis mechanical gimbal, with its angular vibration range reduced to 0.005. Set in a triangular formation, gimbal dampeners help create even steadier shots. 32 MP Sphere Panoramas In addition to Horizontal, Vertical, and 180 panoramas, the Mavic Air stitches 25 photos together in just eight seconds to create crystal-clear 32 MP Sphere panoramas.1 View them from an immersive perspective with DJI Goggles. 4K 100 Mbps Video The Mavic Air shoots video at an incredible 4K 30 fps, recording at 100 Mbps to capture every second with UHD quality. View larger View larger View larger View larger Slow-Motion Video With support for recording 1080p 120 fps slow-motion video, the Mavic Air captures all your epic high-speed adventures. HDR Photos New HDR algorithms help you obtain the right exposure settings intelligently, according to lighting conditions. Overexposed or dark areas are processed for more natural transitions between highlights and shadows, while DSP acceleration allows for more efficient shooting. Geometric Elegance Expressing geometric precision, the Mavic Air's arms fold flush against its aerodynamic chassis. Magnesium alloy brackets reinforce the seven onboard cameras, rear vents dissipate heat efficiently, and the primary gimbal camera is recessed for better protection. 3D Foldable Design As tall and wide as a smartphone when folded, the Mavic Air is an ultraportable drone that stretches the boundaries of what's possible for a device its size. View larger View larger View larger View larger Foldable Remote Controller The dedicated remote controller uses a foldable, low-profile, ergonomic design to hold your smartphone for maximum convenience. Detachable control sticks store inside the remote controller to pack more comfortably on the go. 8 GB Internal Storage In addition to a Micro SD card slot, 8 GB of internal storage let you save photos and videos directly to the aircraft and export files through its USB 3.0 Type-C port. ActiveTrack ActiveTrack can sense up to 16 selectable subjects simultaneously,2 letting you choose the right tracking subject. With higher tracking precision and broader scenario applications, ActiveTrack follows targets even when they're running, jumping, or cycling. QuickShots Choose from six different QuickShots Rocket, Dronie, Circle, Helix, Asteroid, and Boomerang. All are just a tap away and will get you those epic selfie drone videos without needing to think about composing your shot. Share your new creations to social media through the DJI GO 4 app instantly. View larger View larger View larger View larger SmartCapture Fun, simple, and intuitive, SmartCapture offers a new and interactive way of controlling the Mavic Air by hand. Launch and control the drone with hand gestures, then take photos or videos however you like. FlightAutonomy 2.0 FlightAutonomy 2.0Using advanced VIO technology, the powerful sensor system in FlightAutonomy 2.0 consists of a primary gimbal camera, forward, backward, and downward dual-vision sensors, downward infrared sensing system, IMU redundancies, and a group of computing cores. Together, they collect and transmit information from the surrounding environment to the high-performance processor for more precise hovering and better flight performance. Advanced Pilot Assistance Systems (APAS) allow the aircraft to bypass obstacles in front of and behind it actively. Your grand adventures of discovery have never been so safe and easy. Max Flight Time: 21 min Mavic Air Intelligent Flight Batteries are made with high-density lithium, offering a substantial flight time of up to 21 minutes for all your adventuring needs. FOC ESCs and Propulsion The application of FOC sinusoidal drive architecture ESCs provides the Mavic Air with a smoother motor commutation process and high overall efficiency of both motors and ESCs. Learn More All words on this page are an ad that was sent-to youIf you rather not get these anymore then please tell us onthis page 872 Alton Road Marysville, OH 43040Cut out your name from our list byentering your information now http://www.perfumefraud.icu/pbcgqk/oqtzqro1giljftik/dE58COPoT3JJmZ1J7_x96SQhofiAEDpHYV6gLSp6jBk/bNZetkKr9XFQ4QBBlcGScgZo5YLdEZFMaAIwd484UGSKdP-VMwxe4W1zUB1p9YULhucEn8PGcQmCWdr3_LzziQ From owner-freebsd-fs@freebsd.org Wed Jun 12 15:12:22 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD21115B918C for ; Wed, 12 Jun 2019 15:12:22 +0000 (UTC) (envelope-from iceni@loosewin.icu) Received: from loosewin.icu (5xhe1jk.ni.net.tr [95.173.172.5]) by mx1.freebsd.org (Postfix) with ESMTP id E6E4580DB5 for ; Wed, 12 Jun 2019 15:12:21 +0000 (UTC) (envelope-from iceni@loosewin.icu) From: "Brain Food" Date: Wed, 12 Jun 2019 10:07:56 -0500 MIME-Version: 1.0 Subject: Increase your IQ by 15 pts this weekend To: Message-ID: X-Rspamd-Queue-Id: E6E4580DB5 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.85 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[loosewin.icu:s=mail]; spamhaus_xbl(0.00)[5.172.173.95.g4jphcdwjq2eyvr5ppcbhhxyzq.zen.dq.spamhaus.net]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.173.172.5]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[loosewin.icu:+]; DMARC_POLICY_ALLOW(-0.50)[loosewin.icu,quarantine]; MX_GOOD(-0.01)[cached: aspmx.l.google.com]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(-2.86)[ip: (-9.69), ipnet: 95.173.172.0/24(-4.88), asn: 51559(0.24), country: TR(0.04)]; ASN(0.00)[asn:51559, ipnet:95.173.172.0/24, country:TR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 15:12:23 -0000 9 Brain-Boosting Benefits (from one 7 second trick) Hey, You know how they say that the average human only unlocks 10% of their mental ability? Well this video has the key to unlocking that OTHER 90%. Yes, its the same video I recently told you about. And yes, it focuses on that simple 7 second trick to boosting brainpower. Now I know brainpower seems a bit vague. So to let you in on what you can expect from following whats shown in the video, have a look: Increased attention span and focusCrystal clear thinkingLightning fast decision-makingThe ability to retain and absorb new, complex information like a spongeBoosted memoryAmplified brain synergy to help your mind work like a fine-tuned machineEnhanced verbal fluency to speak eloquently with ease and relay your thoughts like a masterImproved overall general moodSky-high ambition like youve NEVER experienced before Thats quite an impressive list. But do you know whats even more impressive? That it can be achieved with nothing more than a simple 7 second trick See it now before its gone If you would like to remove yourself from this email list, please click here . or write us here265 S. Schoolhouse St. Boynton Beach, FL 33435 From owner-freebsd-fs@freebsd.org Thu Jun 13 21:44:05 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0108915BDFA7 for ; Thu, 13 Jun 2019 21:44:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670077.outbound.protection.outlook.com [40.107.67.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FA386FB48; Thu, 13 Jun 2019 21:44:02 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM (52.132.93.160) by YQXPR01MB2743.CANPRD01.PROD.OUTLOOK.COM (52.132.92.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Thu, 13 Jun 2019 21:44:01 +0000 Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::4882:9001:520a:7453]) by YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::4882:9001:520a:7453%5]) with mapi id 15.20.1987.012; Thu, 13 Jun 2019 21:44:01 +0000 From: Rick Macklem To: "freebsd-fs@freebsd.org" CC: "kib@freebsd.org" , Alan Somers , Brooks Davis Subject: RFC: should the copy_file_range() syscall be atomic? Thread-Topic: RFC: should the copy_file_range() syscall be atomic? Thread-Index: AQHVIi1PBuOR1YGquUCvHoiFxEOa/Q== Date: Thu, 13 Jun 2019 21:44:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5a99c37-15b7-46db-603c-08d6f0483f92 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YQXPR01MB2743; x-ms-traffictypediagnostic: YQXPR01MB2743: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(39860400002)(136003)(376002)(396003)(346002)(199004)(189003)(99286004)(74482002)(46003)(8936002)(2351001)(2501003)(186003)(81166006)(6916009)(53936002)(81156014)(86362001)(786003)(316002)(8676002)(33656002)(54906003)(25786009)(4326008)(478600001)(76116006)(64756008)(66446008)(66946007)(73956011)(66476007)(14454004)(68736007)(71200400001)(5660300002)(71190400001)(450100002)(52536014)(486006)(55016002)(102836004)(7696005)(6506007)(9686003)(66556008)(305945005)(74316002)(256004)(6436002)(14444005)(476003)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR01MB2743; H:YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +ZOBprmbYepkkFq7NgfgH55SGwyUIBz1LwlHGeG7G2km5WE3JvYFbhJVqMG96GSyvTUjNJAiUGjZdoJm6UQv5aesifPvJ1AmSUqpFFgTkpNw7+aVLh8HWFH9eWbw4J8EwpcMWWyCcmaAGuOObL0KA4VnRnSl9ATrkUzSKJCAeW23ca2ymCWHk5900RqzlARBXv2LWAzmV55DBTMjv4sDm+V1EMRjBsblXw1AjY5kW/JC3E6dLQ4OYnSSluwDFzn7b0PLf2V9rVRhxPNJ3wztgMQCVlW22C4HV8XYYQ1mr/rzLuvr5gH6ar8j+spDowl/YOBctvctbKz6a7kFWxyNz0SThLxONaJre1VI/6lBF/yB2BBR6G9PzBCGs4SLIlnM2zxHbiQrGZnlZWtV+UHwuokn1PDA111KLUGDmtU40cc= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: e5a99c37-15b7-46db-603c-08d6f0483f92 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 21:44:01.3453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2743 X-Rspamd-Queue-Id: 0FA386FB48 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.77 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-2.95 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.02)[ipnet: 40.64.0.0/10(-2.86), asn: 8075(-2.16), country: US(-0.06)]; MX_GOOD(-0.01)[mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com,mx2.hc184-76.ca.iphmx.com,mx1.hc184-76.ca.iphmx.com]; NEURAL_HAM_SHORT(-0.63)[-0.626,0]; RCVD_IN_DNSWL_NONE(0.00)[77.67.107.40.list.dnswl.org : 127.0.3.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 21:44:05 -0000 When I first wrote the copy_file_range() syscall, the updating of the file = was atomic, because I locked both vnodes while doing it. kib@ quickly pointed out that this could introduce a LOR/deadlock because t= wo userland threads could concurrently do the syscall with the file arguments = reversed. It turns out that locking two VREG vnodes concurrently to do this isn't eas= y and would require the implementation of non-blocking versions of: vn_rangelock_rlock() and vn_rangelock_wlock() - I am not sure how difficult doing this is, but I'll admit I'd rather no= t do this. Also, having the vnodes locked precludes use of VOP_IOCTL(..FIOSEEKDATA/ FIOSEEKHOLE..) calls to find holes in the byte range of the file being copi= ed from. Without the vnodes locked, it is possible for other threads to write to eit= her of the files concurrently with the copy_file_range(), resulting in an indeterminat= e results. (cp(1) has never guaranteed atomic copying of files, so is it needed in thi= s syscall?) In summary, doing the syscall non-atomically has the advantages of: - vn_rdwr() takes care of the vnode locking issues, so any changes w.r.t. l= ocking wouldn't require changes to this syscall's code. - VOP_IOCTL() could be used to find holes. - No new rangelock primitives need to be added to the system. - If there were some combination of file system/storage unit where copying non-overlapping byte ranges concurrently could result in better performan= ce, then that could be done. (An atomic syscall would serialize them.) The advantage of an atomic syscall would be consistency with write(2) and r= ead(2) behaviour. The following comments are copied from phabricator: kib@ - So you relock range for each chunk ? This defeats the purpose of the= range locking. Should copy_file_range() be atomic WRT other reads and writ= es ? asomers@ - That has an unfortunate side effect: copy_file_range is no longe= r atomic if you drop the vnode locks and range locks in the middle. It woul= d be possible for two copy_file_range operations to proceed concurrently, l= eaving the file in a state where each of the operations was partially succe= ssful. A better solution would be to add rangelock_trywlock and rangelock_t= ryrlock. I don't think it would be very hard (testing them, however, could = be). I don't see anything in the Linux man page w.r.t. atomicity, so I am now as= king what others think? (I'll admit I'm biased towards non-atomic, since I have already coded it an= d can use the VOP_IOCTL() calls to find the holes in the input file, but...) rick From owner-freebsd-fs@freebsd.org Thu Jun 13 22:08:24 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A932715BE8C6 for ; Thu, 13 Jun 2019 22:08:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 149C7705E2; Thu, 13 Jun 2019 22:08:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x5DM8F52050195 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Jun 2019 01:08:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x5DM8F52050195 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x5DM8F4g050192; Fri, 14 Jun 2019 01:08:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Jun 2019 01:08:15 +0300 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-fs@freebsd.org" , Alan Somers , Brooks Davis Subject: Re: RFC: should the copy_file_range() syscall be atomic? Message-ID: <20190613220815.GB8697@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 22:08:24 -0000 On Thu, Jun 13, 2019 at 09:44:01PM +0000, Rick Macklem wrote: > When I first wrote the copy_file_range() syscall, the updating of the file was atomic, > because I locked both vnodes while doing it. > kib@ quickly pointed out that this could introduce a LOR/deadlock because two > userland threads could concurrently do the syscall with the file arguments reversed. > > It turns out that locking two VREG vnodes concurrently to do this isn't easy and > would require the implementation of non-blocking versions of: > vn_rangelock_rlock() and vn_rangelock_wlock() > - I am not sure how difficult doing this is, but I'll admit I'd rather not do this. I will help you with this. It should be relatively easy, even if requires some code re-shuffling. > > Also, having the vnodes locked precludes use of VOP_IOCTL(..FIOSEEKDATA/ > FIOSEEKHOLE..) calls to find holes in the byte range of the file being copied from. If you lock ranges, you still can do ioctl. But in fact it might be better to extract wrapper for FIOSEEK* into kernel function, and use it in the ioctl handler and in the copy syscall. > > Without the vnodes locked, it is possible for other threads to write to either of the > files concurrently with the copy_file_range(), resulting in an indeterminate results. > (cp(1) has never guaranteed atomic copying of files, so is it needed in this syscall?) > In summary, doing the syscall non-atomically has the advantages of: > - vn_rdwr() takes care of the vnode locking issues, so any changes w.r.t. locking > wouldn't require changes to this syscall's code. > - VOP_IOCTL() could be used to find holes. > - No new rangelock primitives need to be added to the system. > - If there were some combination of file system/storage unit where copying > non-overlapping byte ranges concurrently could result in better performance, > then that could be done. (An atomic syscall would serialize them.) > > The advantage of an atomic syscall would be consistency with write(2) and read(2) > behaviour. > > The following comments are copied from phabricator: > kib@ - So you relock range for each chunk ? This defeats the purpose of the range locking. Should copy_file_range() be atomic WRT other reads and writes ? > > asomers@ - That has an unfortunate side effect: copy_file_range is no longer atomic if you drop the vnode locks and range locks in the middle. It would be possible for two copy_file_range operations to proceed concurrently, leaving the file in a state where each of the operations was partially successful. A better solution would be to add rangelock_trywlock and rangelock_tryrlock. I don't think it would be very hard (testing them, however, could be). > > I don't see anything in the Linux man page w.r.t. atomicity, so I am now asking what > others think? > (I'll admit I'm biased towards non-atomic, since I have already coded it and can use > the VOP_IOCTL() calls to find the holes in the input file, but...) AFAIK, linux does not provide atomicity for file reads and writes at all, even for normal reads and writes. I do not want to read Linux code to confirm this. From owner-freebsd-fs@freebsd.org Thu Jun 13 22:25:49 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D395415BEFC8 for ; Thu, 13 Jun 2019 22:25:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C9FF70EBE; Thu, 13 Jun 2019 22:25:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f194.google.com with SMTP id h10so352463ljg.0; Thu, 13 Jun 2019 15:25:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pEhTHyhkU7XfhJbWAdyCfrpPrFQbcAvz7qhBtAyfnPw=; b=U7lW1D3FCF1QZgg9bXRWhUUmG4anodjcUms7H99uB/GU0/QLyGGiz3cxVz0CA+68bF KC82ZtRft19vJkyslWHhBHCYKSl9davdsMK4vAKQbcyY1B4Idg8LkOouXnL/lr0aVPnb 0LuvE0qgj35TeAtRIKVCXA4YDHMQ/5mVh0EYLYbkzZJ88GufVC+MEVRhQ7G7oEFIjgVC ZXbnNZzuVkk84H9BT2S38QrkRA8ZUPnUYIgNVtOzk9mPS6V0Kw4e+zOby2Lao9OEnYTD flXQtEQHZIZm+dbVRQclvtYqVmOpA0qw637Fem8NYxRFxI9Yd4kSflLI9hinpcWsSkFw Ospg== X-Gm-Message-State: APjAAAURDz2l6RnzlXXx5QZ8lna6p2xzIyP3t6WtjTmRQIpy8D+CEBLM qwMOAxYx71hzdJOmd65XVasUfLNMSDwJk/MxteigXLzG X-Google-Smtp-Source: APXvYqwVERotSi0n2MApYLTqE3up7Ds5beC68O+ssMEikECsd+U/3k07Imbb/hAABw4jP4WcYNQ+T0vUGuk5vijSCno= X-Received: by 2002:a2e:6e0c:: with SMTP id j12mr25598309ljc.123.1560464741119; Thu, 13 Jun 2019 15:25:41 -0700 (PDT) MIME-Version: 1.0 References: <20190613220815.GB8697@kib.kiev.ua> In-Reply-To: <20190613220815.GB8697@kib.kiev.ua> From: Alan Somers Date: Thu, 13 Jun 2019 16:25:29 -0600 Message-ID: Subject: Re: RFC: should the copy_file_range() syscall be atomic? To: Konstantin Belousov Cc: Rick Macklem , "freebsd-fs@freebsd.org" , Brooks Davis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4C9FF70EBE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.965,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 22:25:49 -0000 On Thu, Jun 13, 2019 at 4:08 PM Konstantin Belousov w= rote: > > On Thu, Jun 13, 2019 at 09:44:01PM +0000, Rick Macklem wrote: > > When I first wrote the copy_file_range() syscall, the updating of the f= ile was atomic, > > because I locked both vnodes while doing it. > > kib@ quickly pointed out that this could introduce a LOR/deadlock becau= se two > > userland threads could concurrently do the syscall with the file argume= nts reversed. > > > > It turns out that locking two VREG vnodes concurrently to do this isn't= easy and > > would require the implementation of non-blocking versions of: > > vn_rangelock_rlock() and vn_rangelock_wlock() > > - I am not sure how difficult doing this is, but I'll admit I'd rathe= r not do this. > I will help you with this. It should be relatively easy, even if require= s > some code re-shuffling. > > > > > Also, having the vnodes locked precludes use of VOP_IOCTL(..FIOSEEKDATA= / > > FIOSEEKHOLE..) calls to find holes in the byte range of the file being = copied from. > If you lock ranges, you still can do ioctl. But in fact it might be bett= er > to extract wrapper for FIOSEEK* into kernel function, and use it in the > ioctl handler and in the copy syscall. > > > > > Without the vnodes locked, it is possible for other threads to write to= either of the > > files concurrently with the copy_file_range(), resulting in an indeterm= inate results. > > (cp(1) has never guaranteed atomic copying of files, so is it needed in= this syscall?) > > In summary, doing the syscall non-atomically has the advantages of: > > - vn_rdwr() takes care of the vnode locking issues, so any changes w.r.= t. locking > > wouldn't require changes to this syscall's code. > > - VOP_IOCTL() could be used to find holes. > > - No new rangelock primitives need to be added to the system. > > - If there were some combination of file system/storage unit where copy= ing > > non-overlapping byte ranges concurrently could result in better perfo= rmance, > > then that could be done. (An atomic syscall would serialize them.) > > > > The advantage of an atomic syscall would be consistency with write(2) a= nd read(2) > > behaviour. > > > > The following comments are copied from phabricator: > > kib@ - So you relock range for each chunk ? This defeats the purpose of= the range locking. Should copy_file_range() be atomic WRT other reads and = writes ? > > > > asomers@ - That has an unfortunate side effect: copy_file_range is no l= onger atomic if you drop the vnode locks and range locks in the middle. It = would be possible for two copy_file_range operations to proceed concurrentl= y, leaving the file in a state where each of the operations was partially s= uccessful. A better solution would be to add rangelock_trywlock and rangelo= ck_tryrlock. I don't think it would be very hard (testing them, however, co= uld be). > > > > I don't see anything in the Linux man page w.r.t. atomicity, so I am no= w asking what > > others think? > > (I'll admit I'm biased towards non-atomic, since I have already coded i= t and can use > > the VOP_IOCTL() calls to find the holes in the input file, but...) > > AFAIK, linux does not provide atomicity for file reads and writes at all, > even for normal reads and writes. I do not want to read Linux code to > confirm this. Really? I find that hard to believe. But sure enough, here's the proof: (they claim it's fixed now) http://man7.org/linux/man-pages/man2/write.2.html . As for copy_file_range, if it's not implemented by the file system, Linux falls back to an implementation based on splice(2). I can't find anything that says whether splice has atomic writes, and in a quick scan of the code I can't find any sign of locking. However, glibc also contains a userland implementation of copy_file_range. It works 8KB at a time and is most definitely NOT atomic. -Alan From owner-freebsd-fs@freebsd.org Thu Jun 13 22:32:42 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E247615BF27B for ; Thu, 13 Jun 2019 22:32:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670052.outbound.protection.outlook.com [40.107.67.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C65A712F6; Thu, 13 Jun 2019 22:32:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM (52.132.93.160) by YQXPR01MB3158.CANPRD01.PROD.OUTLOOK.COM (52.132.90.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Thu, 13 Jun 2019 22:32:39 +0000 Received: from YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::4882:9001:520a:7453]) by YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM ([fe80::4882:9001:520a:7453%5]) with mapi id 15.20.1987.012; Thu, 13 Jun 2019 22:32:39 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-fs@freebsd.org" , Alan Somers , Brooks Davis Subject: Re: RFC: should the copy_file_range() syscall be atomic? Thread-Topic: RFC: should the copy_file_range() syscall be atomic? Thread-Index: AQHVIi1PBuOR1YGquUCvHoiFxEOa/aaaJKSAgAABx3U= Date: Thu, 13 Jun 2019 22:32:39 +0000 Message-ID: References: , <20190613220815.GB8697@kib.kiev.ua> In-Reply-To: <20190613220815.GB8697@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d4fb0630-d7a3-467c-72db-08d6f04f0ad8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:YQXPR01MB3158; x-ms-traffictypediagnostic: YQXPR01MB3158: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(366004)(346002)(39860400002)(199004)(189003)(6246003)(186003)(6436002)(53936002)(478600001)(99286004)(33656002)(229853002)(102836004)(14454004)(55016002)(6506007)(54906003)(9686003)(316002)(786003)(14444005)(256004)(74316002)(446003)(11346002)(2906002)(76176011)(305945005)(74482002)(5660300002)(6916009)(81156014)(86362001)(68736007)(7696005)(1411001)(476003)(486006)(8936002)(71200400001)(71190400001)(25786009)(76116006)(66446008)(66476007)(64756008)(66946007)(66556008)(73956011)(52536014)(4326008)(46003)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQXPR01MB3158; H:YQXPR01MB3128.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YsKjZJ2OWuMfSfpur+l2kH8vN8dACRzR3X8U3eWtrTCjAjnXc7PG0Xe94bkqBrBKq+jtzg+DxKMDfaJ2awVOAQf1GgTCyOS6fn3mMGmbs0EEpRS/YIfi2DJnMtt7BH3X7iBpl/JcSMqKKRK/uUVlKHv+csXXStDFngj/WMFvTU5Knx6g3sw65WkitesK/3TzQX7n7xK81fh5TY3xrEmaXwY6bWAzTkvJBgyNkYbJRb5ieoK+auR+IsJbBmOR8LW2gfFUirE0ZxAqAL5C172uagSvQTCv2PH6NXOIOokfIyGhLvFN0MK8NKrpmItJabVgQEG8bIjqK1ZzuiBsY+d/NthEwdB7XCFVvLSEGIWsywYvGLrN8kDehHmM1oOHoOepf9AcLl+tMZEeKq8e5/+SwlQNC1kVkAUeDg+48OrGZuc= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: d4fb0630-d7a3-467c-72db-08d6f04f0ad8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 22:32:39.3224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rmacklem@uoguelph.ca X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3158 X-Rspamd-Queue-Id: 7C65A712F6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968,0] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 22:32:42 -0000 Konstantin Belousov wrote: >On Thu, Jun 13, 2019 at 09:44:01PM +0000, Rick Macklem wrote: >> When I first wrote the copy_file_range() syscall, the updating of the fi= le was atomic, >> because I locked both vnodes while doing it. >> kib@ quickly pointed out that this could introduce a LOR/deadlock becaus= e two >> userland threads could concurrently do the syscall with the file argumen= ts reversed. >> >> It turns out that locking two VREG vnodes concurrently to do this isn't = easy and >> would require the implementation of non-blocking versions of: >> vn_rangelock_rlock() and vn_rangelock_wlock() >> - I am not sure how difficult doing this is, but I'll admit I'd rather= not do this. >I will help you with this. It should be relatively easy, even if requires >some code re-shuffling. Ok, I'll wait a while to see if others think this should be done. Then if t= hey do, I'll take a first stab at it and then pass it along to you. >> >> Also, having the vnodes locked precludes use of VOP_IOCTL(..FIOSEEKDATA/ >> FIOSEEKHOLE..) calls to find holes in the byte range of the file being c= opied from. >If you lock ranges, you still can do ioctl. Ok, so you are proposing to lock the byte ranges, but lock/unlock the vnode= s and do the vn_start_write()/vn_finished_write() for each block read/written= so the FIOSEEK* can be done in the loop? That sounds fine with me, once the concurrent range locks can be acquired s= afely. > But in fact it might be better >to extract wrapper for FIOSEEK* into kernel function, and use it in the >ioctl handler and in the copy syscall. It's just a VOP_IOCTL() call, so I don't see a need to wrap it? (The only trick is that the vnode must be unlocked when you do the call.) >> >> Without the vnodes locked, it is possible for other threads to write to = either of the >> files concurrently with the copy_file_range(), resulting in an indetermi= nate results. >> (cp(1) has never guaranteed atomic copying of files, so is it needed in = this syscall?) >> In summary, doing the syscall non-atomically has the advantages of: >> - vn_rdwr() takes care of the vnode locking issues, so any changes w.r.t= . locking >> wouldn't require changes to this syscall's code. >> - VOP_IOCTL() could be used to find holes. >> - No new rangelock primitives need to be added to the system. >> - If there were some combination of file system/storage unit where copyi= ng >> non-overlapping byte ranges concurrently could result in better perfor= mance, >> then that could be done. (An atomic syscall would serialize them.) >> >> The advantage of an atomic syscall would be consistency with write(2) an= d read(2) >> behaviour. >> >> The following comments are copied from phabricator: >> kib@ - So you relock range for each chunk ? This defeats the purpose of = the range locking. Should copy_file_range() be atomic WRT other reads and w= rites ? >> >> asomers@ - That has an unfortunate side effect: copy_file_range is no lo= nger atomic if you drop the vnode locks and range locks in the middle. It w= ould be possible for two copy_file_range operations to proceed concurrently= , leaving the file in a state where each of the operations was partially su= ccessful. A better solution would be to add rangelock_trywlock and rangeloc= k_tryrlock. I don't think it would be very hard (testing them, however, cou= ld be). >> >> I don't see anything in the Linux man page w.r.t. atomicity, so I am now= asking what >> others think? >> (I'll admit I'm biased towards non-atomic, since I have already coded it= and can use >> the VOP_IOCTL() calls to find the holes in the input file, but...) > >AFAIK, linux does not provide atomicity for file reads and writes at all, >even for normal reads and writes. I do not want to read Linux code to >confirm this. Heh, heh. I don't want to read Linux code to verify this either;-) I end up reading their NFS code once in a while, but that's enough for me. However, it does mean that no one will expect atomic behaviour if Linux doe= sn't provide it. One amusing property of this syscall is that it fails if offset+len exceeds= EOF. The example in the Linux man page first stat(2)s the input file to find out= its size and then copies that much using copy_file_range(2) in a loop. Of course, if the size changes between the stat(2) and the copy_file_range(= 2) calls, all bets are off. Also, the Linux man page says it can return having copied less than request= ed, although it doesn't explain when/why. It does state that exceeding EOF retu= rns EINVAL, so it isn't that it hits EOF on the input file. From owner-freebsd-fs@freebsd.org Thu Jun 13 23:02:09 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C06BB15BFB9E for ; Thu, 13 Jun 2019 23:02:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B82F71DB7; Thu, 13 Jun 2019 23:02:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x5DN213g099464 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 14 Jun 2019 02:02:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x5DN213g099464 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x5DN218l099463; Fri, 14 Jun 2019 02:02:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Jun 2019 02:02:01 +0300 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-fs@freebsd.org" , Alan Somers , Brooks Davis Subject: Re: RFC: should the copy_file_range() syscall be atomic? Message-ID: <20190613230201.GC8697@kib.kiev.ua> References: <20190613220815.GB8697@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 23:02:10 -0000 On Thu, Jun 13, 2019 at 10:32:39PM +0000, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Thu, Jun 13, 2019 at 09:44:01PM +0000, Rick Macklem wrote: > >> When I first wrote the copy_file_range() syscall, the updating of the file was atomic, > >> because I locked both vnodes while doing it. > >> kib@ quickly pointed out that this could introduce a LOR/deadlock because two > >> userland threads could concurrently do the syscall with the file arguments reversed. > >> > >> It turns out that locking two VREG vnodes concurrently to do this isn't easy and > >> would require the implementation of non-blocking versions of: > >> vn_rangelock_rlock() and vn_rangelock_wlock() > >> - I am not sure how difficult doing this is, but I'll admit I'd rather not do this. > >I will help you with this. It should be relatively easy, even if requires > >some code re-shuffling. > Ok, I'll wait a while to see if others think this should be done. Then if they do, I'll > take a first stab at it and then pass it along to you. > > >> > >> Also, having the vnodes locked precludes use of VOP_IOCTL(..FIOSEEKDATA/ > >> FIOSEEKHOLE..) calls to find holes in the byte range of the file being copied from. > >If you lock ranges, you still can do ioctl. > Ok, so you are proposing to lock the byte ranges, but lock/unlock the vnodes > and do the vn_start_write()/vn_finished_write() for each block read/written so the FIOSEEK* can be done in the loop? > > That sounds fine with me, once the concurrent range locks can be acquired safely. Yes, the range locks should be acquired with the same algorithm as for the vnode locks. Then you can lock/unlock vnodes as needed. This is how our read(2) and write(2) work already. > > > But in fact it might be better > >to extract wrapper for FIOSEEK* into kernel function, and use it in the > >ioctl handler and in the copy syscall. > It's just a VOP_IOCTL() call, so I don't see a need to wrap it? > (The only trick is that the vnode must be unlocked when you do the call.) You mean that you would call VOP_IOCTL() directly ? I see. > > >> > >> Without the vnodes locked, it is possible for other threads to write to either of the > >> files concurrently with the copy_file_range(), resulting in an indeterminate results. > >> (cp(1) has never guaranteed atomic copying of files, so is it needed in this syscall?) > >> In summary, doing the syscall non-atomically has the advantages of: > >> - vn_rdwr() takes care of the vnode locking issues, so any changes w.r.t. locking > >> wouldn't require changes to this syscall's code. > >> - VOP_IOCTL() could be used to find holes. > >> - No new rangelock primitives need to be added to the system. > >> - If there were some combination of file system/storage unit where copying > >> non-overlapping byte ranges concurrently could result in better performance, > >> then that could be done. (An atomic syscall would serialize them.) > >> > >> The advantage of an atomic syscall would be consistency with write(2) and read(2) > >> behaviour. > >> > >> The following comments are copied from phabricator: > >> kib@ - So you relock range for each chunk ? This defeats the purpose of the range locking. Should copy_file_range() be atomic WRT other reads and writes ? > >> > >> asomers@ - That has an unfortunate side effect: copy_file_range is no longer atomic if you drop the vnode locks and range locks in the middle. It would be possible for two copy_file_range operations to proceed concurrently, leaving the file in a state where each of the operations was partially successful. A better solution would be to add rangelock_trywlock and rangelock_tryrlock. I don't think it would be very hard (testing them, however, could be). > >> > >> I don't see anything in the Linux man page w.r.t. atomicity, so I am now asking what > >> others think? > >> (I'll admit I'm biased towards non-atomic, since I have already coded it and can use > >> the VOP_IOCTL() calls to find the holes in the input file, but...) > > > >AFAIK, linux does not provide atomicity for file reads and writes at all, > >even for normal reads and writes. I do not want to read Linux code to > >confirm this. > Heh, heh. I don't want to read Linux code to verify this either;-) > I end up reading their NFS code once in a while, but that's enough for me. > > However, it does mean that no one will expect atomic behaviour if Linux doesn't > provide it. Well, even if Linux does not provide atomic reads and writes, we still do and we find this useful. > > One amusing property of this syscall is that it fails if offset+len exceeds EOF. > The example in the Linux man page first stat(2)s the input file to find out its > size and then copies that much using copy_file_range(2) in a loop. > Of course, if the size changes between the stat(2) and the copy_file_range(2) > calls, all bets are off. > Also, the Linux man page says it can return having copied less than requested, > although it doesn't explain when/why. It does state that exceeding EOF returns > EINVAL, so it isn't that it hits EOF on the input file. From owner-freebsd-fs@freebsd.org Fri Jun 14 08:51:27 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 254EB15CACCB for ; Fri, 14 Jun 2019 08:51:27 +0000 (UTC) (envelope-from citizen@squashsettle.icu) Received: from squashsettle.icu (2m2zx11m.ni.net.tr [89.252.175.149]) by mx1.freebsd.org (Postfix) with ESMTP id 3D05F8A0F3 for ; Fri, 14 Jun 2019 08:51:26 +0000 (UTC) (envelope-from citizen@squashsettle.icu) From: " Francisco Nunez" Date: Fri, 14 Jun 2019 03:48:51 -0500 MIME-Version: 1.0 Subject: Airconditioners are becoming obsolete because of this... To: Message-ID: X-Spamd-Bar: +++++ X-Rspamd-Fuzzy: 0c46adff95777a0b1470b0def8ec2d361852087eea57185f03a148a6c10a1eaa024b6e892540cdd6a3cd36a257974e3b0d88299ea4de0e7606582e206654ddf8 X-Rspamd-Fuzzy: 0c46adff95777a0b1470b0def8ec2d361852087eea57185f03a148a6c10a1eaa024b6e892540cdd6a3cd36a257974e3b0d88299ea4de0e7606582e206654ddf8 X-Spamd-Result: default: False [5.28 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[squashsettle.icu:s=mail]; spamhaus_xbl(0.00)[149.175.252.89.g4jphcdwjq2eyvr5ppcbhhxyzq.zen.dq.spamhaus.net]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:89.252.175.149]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; HTML_SHORT_LINK_IMG_2(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_MEDIUM(0.97)[0.970,0]; FUZZY_DENIED(0.00)[1:0c46adff95:0.69:txt]; DKIM_TRACE(0.00)[squashsettle.icu:+]; DMARC_POLICY_ALLOW(0.00)[squashsettle.icu,quarantine]; NEURAL_SPAM_LONG(1.00)[0.999,0]; MX_GOOD(-0.01)[cached: aspmx.l.google.com]; NEURAL_SPAM_SHORT(0.96)[0.957,0]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(1.36)[ipnet: 89.252.175.0/24(4.49), asn: 51559(2.27), country: TR(0.05)]; ASN(0.00)[asn:51559, ipnet:89.252.175.0/24, country:TR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 3D05F8A0F3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 08:51:27 -0000 New Personal Air Cooler Brings Revolution on Cooling Devices Summer may be a beautiful season, but long hot days in the heat can become a nightmare. You may even find it difficult to cope with daily routine, particularly when youre trying to work, relax, or sleep. Does this sound familiar? CoolAir Benefits Fast cooling - In less than 60 seconds you will enjoy the benefits of a wonderful, temperature controlled personal space.Extremely quiet fan and soothing night light - Perfect to use throughout the night for a comfortable sleep.Compact and portable - You can plug it into your office or any room of your house via a plug or USB port.3-Speed Fan - Ideal for all your needs. Try it when sleeping, working, or playing sports.Long-Lasting Tank - Fill it with water and no need to refill for the next 8 hours For a limited time only, EXCLUSIVE OFFER for our visitors: GET YOURS NOW with 50% DISCOUNT and Free Shipping Worldwide! 721 North High Point Court Apex, NC 27502 Don't like these emails? Get removed! . From owner-freebsd-fs@freebsd.org Fri Jun 14 18:19:16 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34CBE15AE693 for ; Fri, 14 Jun 2019 18:19:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BF64374581 for ; Fri, 14 Jun 2019 18:19:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 794FE15AE68A; Fri, 14 Jun 2019 18:19:15 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 655DD15AE687 for ; Fri, 14 Jun 2019 18:19:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE24A7457F for ; Fri, 14 Jun 2019 18:19:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 21F991795 for ; Fri, 14 Jun 2019 18:19:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5EIJDlZ072784 for ; Fri, 14 Jun 2019 18:19:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5EIIuBr072730 for fs@FreeBSD.org; Fri, 14 Jun 2019 18:18:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 238565] panic: vinvalbuf: dirty bufs during unmount if clustered writes return errors Date: Fri, 14 Jun 2019 18:18: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: asomers@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2019 18:19:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238565 Alan Somers changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Jun 15 10:52:32 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 506F015C3BF0 for ; Sat, 15 Jun 2019 10:52:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B87E2711F3 for ; Sat, 15 Jun 2019 10:52:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 77A3E15C3BEF; Sat, 15 Jun 2019 10:52:31 +0000 (UTC) Delivered-To: fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64E7015C3BEE for ; Sat, 15 Jun 2019 10:52:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBE05711EC for ; Sat, 15 Jun 2019 10:52:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 1D165A85B for ; Sat, 15 Jun 2019 10:52:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5FAqTqO098367 for ; Sat, 15 Jun 2019 10:52:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5FAqTYF098366 for fs@FreeBSD.org; Sat, 15 Jun 2019 10:52:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 231211] [zfs] possible deadlock triggered by zfs test suite Date: Sat, 15 Jun 2019 10:52:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: stefanrink@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 10:52:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231211 Stefan Rink changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefanrink@yahoo.com --- Comment #2 from Stefan Rink --- I hit this bug on a bhyve with UFS filesystem on 13-current! thread 100377 (pid 36752, sh) blocked on lockmgr ufsEXCL thread 100078 (pid 22, syncer) blocked on lockmgr bufwaitEXCL It's still in KDB but I can only access the console via VNC so can't copy/p= aste text, dump it or make screenshots. Trace of the sh process that started this; sched_switch() mi_switch() sleepq_switch() sleepq_wait() sleeplk() lockmgr_slock_hard() __lockmgr_args() ffs_lock() VOP_LOCK1_APV() _vn_lock() vget() cache_lookup() vfs_cache_lookup() VOP_LOOKUP_APV() lookup() namei() vn_open_cred() kern_openat() amd64_syscall() -=20 Need any more info? --=20 You are receiving this mail because: You are the assignee for the bug.=