From owner-freebsd-fs@freebsd.org Sun Dec 18 21:00:48 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C4E4C87E3A for ; Sun, 18 Dec 2016 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F0F21B3B for ; Sun, 18 Dec 2016 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBIL01lA091064 for ; Sun, 18 Dec 2016 21:00:47 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201612182100.uBIL01lA091064@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention Date: Sun, 18 Dec 2016 21:00:47 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 21:00:48 -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 | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 140068 | [smbfs] [patch] smbfs does not allow semicolon in Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f Open | 203419 | solaris assert: (dn->dn_phys->dn_nlevels == 0 && Open | 211491 | System hangs after "Uptime" on reboot with ZFS 7 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Dec 19 05:55:14 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF01BC87421 for ; Mon, 19 Dec 2016 05:55:14 +0000 (UTC) (envelope-from 0100015915a5eb1d-65f1e4a1-549d-47a4-9aaf-3ba9f191ec44-000000@amazonses.com) Received: from a8-176.smtp-out.amazonses.com (a8-176.smtp-out.amazonses.com [54.240.8.176]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 701431D7A for ; Mon, 19 Dec 2016 05:55:14 +0000 (UTC) (envelope-from 0100015915a5eb1d-65f1e4a1-549d-47a4-9aaf-3ba9f191ec44-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1482126912; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=ZaSX9VqgCy9AZiG3Kew08gl06x7XT1zc5kge0QTeuy0=; b=hqE+lxsR3pkBMh8PkPQ54LzNFkEY8YKMmLAcPKFe9YuIte5Nw+b1AYb5Oef9sQtw D2jEOpWShh0y4bZA0iOVEwvFn/5PrMDX1nyt7uGezaTji/1UztAq1eK2/QEgOWzHY2D GQHxzMvuxk5WSXohweXgwDCeC1rEuSHwJqXuoEyY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1482126912; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=ZaSX9VqgCy9AZiG3Kew08gl06x7XT1zc5kge0QTeuy0=; b=GkPx8KlWRwsRK5mmkQw3pIdEtBRGhlAnj45zn5pr5mD5fySNcPL4X39PFdB1tJZR hXcjqEJ3gshkY0LHAoABJejHv2QvSKKY3kCJFklhgjCqtfqJneCzXHevDaK+qyBIFBd BfIXsFw+l5XZJYrJrG4qO2Y4FhM8lrmdqOjWhFWo= Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> <20161212054233.GU8460@kduck.kaduk.org> <01000158f1abc081-d4eddc58-3b4b-41dd-aa1e-0157d2fad812-000000@email.amazonses.com> <20161212163603.GV8460@kduck.kaduk.org> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com> Cc: "freebsd-fs@freebsd.org" From: Colin Percival Message-ID: <0100015915a5eb1d-65f1e4a1-549d-47a4-9aaf-3ba9f191ec44-000000@email.amazonses.com> Date: Mon, 19 Dec 2016 05:55:12 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.19-54.240.8.176 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 05:55:14 -0000 On 12/16/16 12:14, Colin Percival wrote: > making this change in nfs_lookup >> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >> @@ -1144,7 +1144,7 @@ >> *vpp = NULLVP; >> } >> >> - if (error != ENOENT) { >> + if (error != ENOENT && error != ESTALE) { >> if (NFS_ISV4(dvp)) >> error = nfscl_maperr(td, error, (uid_t)0, >> (gid_t)0); > > fixes the case I described above (for some definition of "fixes" -- I'm not > sure if this is the correct way of handling ESTALE here?) but I'm still seeing > ESTALEs from buildworld's cleandir so I think there must be some other place > where something odd is happening. Further information: In addition to the "lookup relative to a directory which has been deleted out from underneath us" case which causes ESTALE to land in nfs_lookup, the cleandir step of buildworld results in ESTALE being returned by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ESTALE being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimately in stat and lstat). In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag and check this in the appropriate nfs_* calls? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Mon Dec 19 23:32:39 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E203BC88A5C for ; Mon, 19 Dec 2016 23:32:39 +0000 (UTC) (envelope-from 01000159196dee7c-b727d595-c8e6-4761-b2a7-197d27f1f21a-000000@amazonses.com) Received: from a8-237.smtp-out.amazonses.com (a8-237.smtp-out.amazonses.com [54.240.8.237]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A17841DC3 for ; Mon, 19 Dec 2016 23:32:39 +0000 (UTC) (envelope-from 01000159196dee7c-b727d595-c8e6-4761-b2a7-197d27f1f21a-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1482190352; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=SxMHYMInz3sByjUr5+aWscY2rnzqaaTsSiWSGuozOAg=; b=U4kFNYriMQs+mGKFD+gdEoc2o9JExz93PfulMFWa1yl60P+VK3E302b+XGz+fSFD kLpCnjfu77KQE99BJSd5JySvG1j+iDbF+6cw4lg8mUJ0ZmXOkcjze7sYTmiFudNH685 EWXq5ebECt6o7c3uJ/rweALQyP4DOhuWnPahtKeg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1482190352; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=SxMHYMInz3sByjUr5+aWscY2rnzqaaTsSiWSGuozOAg=; b=fE054Jy0jSVEuUb/PNaGZ3Yzsv+FLOAcIYFWOKJcRmHTDjXHgwoJ9ZWa3s+veltI 4xBNrkRQhtNadysoC8V50DuhqP2/OK1uL7AcpmFcijGxpGVM7AynioTBV6IoMeo0VIr yLb/dFr9QsdvzkrBbaHLi8gRqexEz4/jMWSM6k1Q= Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> <20161212054233.GU8460@kduck.kaduk.org> <01000158f1abc081-d4eddc58-3b4b-41dd-aa1e-0157d2fad812-000000@email.amazonses.com> <20161212163603.GV8460@kduck.kaduk.org> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com> <0100015915a5ee96-49de6100-5050-4a0a-a3c9-1bd4215bc6a0-000000@email.amazonses.com> Cc: "freebsd-fs@freebsd.org" From: Colin Percival Message-ID: <01000159196dee7c-b727d595-c8e6-4761-b2a7-197d27f1f21a-000000@email.amazonses.com> Date: Mon, 19 Dec 2016 23:32:32 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.19-54.240.8.237 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 23:32:40 -0000 On 12/19/16 13:59, Rick Macklem wrote: > Colin Percival wrote: >> Further information: In addition to the "lookup relative to a directory which >> has been deleted out from underneath us" case which causes ESTALE to land in >> nfs_lookup, the cleandir step of buildworld results in ESTALE being returned >> by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ESTALE >> being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimately >> in stat and lstat). >> >> In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup >> returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag >> and check this in the appropriate nfs_* calls? > To be honest, I can't think of a reason why userland would ever want to see ESTALE? > The function you see above "nfscl_maperr()" could easily map all ESTALEs to ENOENTs? I was wondering about that. I hesitated to suggest it since it seemed like doing this could mask bugs and/or throw away useful information -- I mean, I assume there was a reason ESTALE existed in the first place... > - The question is: "Would returning ENOENT for stat(2) and access(2) actually make the > buildworld happy? I think buildworld would need s/ESTALE/ENOENT/ in access, lstat, rmdir, stat, and unlink. But with those I'm 99% confident that buildworld will complete. > --> The cheat for regular files is "sillyrename". This could be done for directories, > but there are multiple comments in the code (not put there by me) that say > "no sillyrename for directories". > #1 Does this imply something breaks when you do sillyrename for dirs? Yes. You'd run into this scenario: $ mkdir /nfs/foo $ cd /nfs/foo $ rmdir /nfs/foo # still in use, sillyrename happens $ touch bar # creates /nfs/foo.sillyname/bar $ cd / # directory no longer in use, time to delete it... Whereas keeping track of "this nfsnode refers to a directory which has been deleted" would allow us to return ENOENT to file-creation attempt, just like UFS does if you try to create a file inside a removed directory. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Tue Dec 20 04:33:48 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1921DC87BA1 for ; Tue, 20 Dec 2016 04:33:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0053.outbound.protection.outlook.com [104.47.33.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B67CA1D83 for ; Tue, 20 Dec 2016 04:33:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Mon, 19 Dec 2016 21:59:59 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Mon, 19 Dec 2016 21:59:59 +0000 From: Rick Macklem To: Colin Percival CC: "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wQ= Date: Mon, 19 Dec 2016 21:59:59 +0000 Message-ID: References: <01000158f023675b-41b35a73-4428-4937-853b-62db4fb9b984-000000@email.amazonses.com> <20161212054233.GU8460@kduck.kaduk.org> <01000158f1abc081-d4eddc58-3b4b-41dd-aa1e-0157d2fad812-000000@email.amazonses.com> <20161212163603.GV8460@kduck.kaduk.org> <01000158fc3da2c5-c13da088-e7b9-4ac0-ac01-ec49a275dd24-000000@email.amazonses.com> <010001590945e9b3-015a4d05-2646-44ba-9db9-415e8b9119dd-000000@email.amazonses.com>, <0100015915a5ee96-49de6100-5050-4a0a-a3c9-1bd4215bc6a0-000000@email.amazonses.com> In-Reply-To: <0100015915a5ee96-49de6100-5050-4a0a-a3c9-1bd4215bc6a0-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 814fc361-6698-4447-255a-08d4285a607e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:JS/pPHYlNv9mSzN9Ib4jyS8EX5Tb4Tc7HSBki4VmmZvAevYhAmRl+JK5cbc6FtRB9svAWZzcMtAClBaXOC/8tekMSl97MgBdF0y6qCb1mPCd8Zm+aomhfvagcClc2747gT2/KdkJr0BrFXWkTe2CMaQKaYHaD9gxpYXoDRFHe6N8HKxBhd9QWlRbJM/XFYaSqcApSZ0B1fNvHvUUZWCkxO/w8zZZGOSbmui3l559/L7AzXmBHwPqpjhAyIlbI5t+Ym9MFdIBPrxIQSPeQLoDaTCU/HFh0G+LVbuvaLCZ2tsm1MrLLzV2KjaPpws2DAjopXLy9Gk1dZrk9pGQZ+C+7bEKvHaMuz9csK0rDG22v6e8oBwysET8AB91Jq+9mNc/yXynvDatSDEJPxoDGtboUjK2duR5YRQ0zrrI0zPE/1Ih+Bi85y64yfyr02zYLnRXpQfco5TS2LojRp0W401wYw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(189002)(199003)(102836003)(189998001)(5660300001)(305945005)(74316002)(8936002)(2950100002)(110136003)(4326007)(2906002)(122556002)(68736007)(6916009)(74482002)(97736004)(76176999)(81166006)(54356999)(106356001)(229853002)(81156014)(77096006)(38730400001)(86362001)(106116001)(6506006)(101416001)(3660700001)(33656002)(6436002)(2900100001)(9686002)(93886004)(92566002)(50986999)(7696004)(3280700002)(8676002)(105586002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 19 Dec 2016 21:59:59.5358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 04:33:48 -0000 Colin Percival wrote: >On 12/16/16 12:14, Colin Percival wrote: >> making this change in nfs_lookup >>> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >>> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >>> @@ -1144,7 +1144,7 @@ >>> *vpp =3D NULLVP; >>> } >>> >>> - if (error !=3D ENOENT) { >>> + if (error !=3D ENOENT && error !=3D ESTALE) { >>> if (NFS_ISV4(dvp)) >>> error =3D nfscl_maperr(td, error, (uid_= t)0, >>> (gid_t)0); >> >> fixes the case I described above (for some definition of "fixes" -- I'm = not >> sure if this is the correct way of handling ESTALE here?) but I'm still = seeing >> ESTALEs from buildworld's cleandir so I think there must be some other p= lace >> where something odd is happening. > >Further information: In addition to the "lookup relative to a directory wh= ich >has been deleted out from underneath us" case which causes ESTALE to land = in >nfs_lookup, the cleandir step of buildworld results in ESTALE being return= ed >by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and EST= ALE >being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimate= ly >in stat and lstat). > >In UFS there are checks for effnlink =3D=3D 0 which result in e.g. ufs_loo= kup >returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_= flag >and check this in the appropriate nfs_* calls? To be honest, I can't think of a reason why userland would ever want to see= ESTALE? The function you see above "nfscl_maperr()" could easily map all ESTALEs to= ENOENTs? - The question is: "Would returning ENOENT for stat(2) and access(2) actual= ly make the buildworld happy? if Yes - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx() = calls. else - I don't see any point in returning a different error and there= might be some code out there somewhere that depends on seeing ESTALE (I doub= t it, but???). The real problem here is that the directory has a reference count on it whe= n it is rmdir'd. POSIX file systems keep the data until the reference count goes to= 0, but NFS isn't POSIX. --> The cheat for regular files is "sillyrename". This could be done for di= rectories, but there are multiple comments in the code (not put there by me) tha= t say "no sillyrename for directories". #1 Does this imply something breaks when you do sillyrename for dirs? OR #2 Does it mean no one has bothered to implement it? Since implementing it would have been pretty easy, I have to suspect #1, wh= ich means I would be reluctant to do it, at least by default. --> Maybe I'll send you a patch that does sillyrename for dirs which you ca= n test. If it fixes buildworld, then it could be considered for head as a non= -default option? rick From owner-freebsd-fs@freebsd.org Tue Dec 20 07:15:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2EA5C89231 for ; Tue, 20 Dec 2016 07:15:19 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BE2E1438 for ; Tue, 20 Dec 2016 07:15:19 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id uBK7FAlL002072; Mon, 19 Dec 2016 23:15:14 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201612200715.uBK7FAlL002072@gw.catspoiler.org> Date: Mon, 19 Dec 2016 23:15:10 -0800 (PST) From: Don Lewis Subject: Re: ESTALE after cwd deleted by same NFS client To: rmacklem@uoguelph.ca cc: cperciva@tarsnap.com, freebsd-fs@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 07:15:19 -0000 On 19 Dec, Rick Macklem wrote: > Colin Percival wrote: > >>On 12/16/16 12:14, Colin Percival wrote: >>> making this change in nfs_lookup >>>> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >>>> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >>>> @@ -1144,7 +1144,7 @@ >>>> *vpp = NULLVP; >>>> } >>>> >>>> - if (error != ENOENT) { >>>> + if (error != ENOENT && error != ESTALE) { >>>> if (NFS_ISV4(dvp)) >>>> error = nfscl_maperr(td, error, (uid_t)0, >>>> (gid_t)0); >>> >>> fixes the case I described above (for some definition of "fixes" -- I'm not >>> sure if this is the correct way of handling ESTALE here?) but I'm still seeing >>> ESTALEs from buildworld's cleandir so I think there must be some other place >>> where something odd is happening. >> >>Further information: In addition to the "lookup relative to a directory which >>has been deleted out from underneath us" case which causes ESTALE to land in >>nfs_lookup, the cleandir step of buildworld results in ESTALE being returned >>by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ESTALE >>being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimately >>in stat and lstat). >> >>In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup >>returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag >>and check this in the appropriate nfs_* calls? > To be honest, I can't think of a reason why userland would ever want to see ESTALE? > The function you see above "nfscl_maperr()" could easily map all ESTALEs to ENOENTs? > - The question is: "Would returning ENOENT for stat(2) and access(2) actually make the > buildworld happy? > if Yes > - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx() calls. > else > - I don't see any point in returning a different error and there might be some > code out there somewhere that depends on seeing ESTALE (I doubt it, but???). > > The real problem here is that the directory has a reference count on it when it is > rmdir'd. POSIX file systems keep the data until the reference count goes to 0, but > NFS isn't POSIX. > --> The cheat for regular files is "sillyrename". This could be done for directories, > but there are multiple comments in the code (not put there by me) that say > "no sillyrename for directories". > #1 Does this imply something breaks when you do sillyrename for dirs? > OR > #2 Does it mean no one has bothered to implement it? > Since implementing it would have been pretty easy, I have to suspect #1, which > means I would be reluctant to do it, at least by default. > --> Maybe I'll send you a patch that does sillyrename for dirs which you can test. > If it fixes buildworld, then it could be considered for head as a non-default option? Sillyrename makes sense for files because you can continue to read and write to a file after it is unlinked, until it is closed and it totally vanishes. It doesn't make sense for directories since you can't rmdir() a directory until it is empty. Once it is rmdir()ed, then you can't create any new entries in the directory because that would mean that you are creating a disconnnected subtree in the filesystem. From owner-freebsd-fs@freebsd.org Tue Dec 20 20:29:38 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D03DC8946C for ; Tue, 20 Dec 2016 20:29:38 +0000 (UTC) (envelope-from livejournal@bekreyev.ru) Received: from sout.wanadoo.co.uk (sout2.wanadoo.co.uk [193.252.22.102]) by mx1.freebsd.org (Postfix) with ESMTP id AA5D4E74 for ; Tue, 20 Dec 2016 20:29:36 +0000 (UTC) (envelope-from livejournal@bekreyev.ru) Received: from xhzhl-PC ([90.157.214.86]) by mwinf5d23 with ME id NLVK1u00F1sQvzN03LVXYc; Tue, 20 Dec 2016 21:29:36 +0100 X-ME-Helo: xhzhl-PC X-ME-Auth: bWlkZ2V0Z2VtQG9yYW5nZS5uZXQ= X-ME-Date: Tue, 20 Dec 2016 21:29:36 +0100 X-ME-IP: 90.157.214.86 From: Chapter ISOC Chapter Support To: "FreeBSD Filesystems" , "ciena" , "Bernhard Kroenung" , "carfreeatoz-com" , "Kevin Oberman" References: <0000b6c7db35$5a5303d4$315c2fc4$@freebsd.org> In-Reply-To: <0000b6c7db35$5a5303d4$315c2fc4$@freebsd.org> Subject: RE: this is simply the coolest stuff ever Date: Tue, 20 Dec 2016 22:29:22 +0200 Message-ID: <1091704380.20161220232922@bekreyev.ru> Content-Language: en-ca Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 20:29:38 -0000 SGV5LA0KSnVzdCB3YW50ZWQgdG8gIHNob3cgdGhhdCBjb29sICBzdHVmZiBJJ3ZlIGp1c3QgZm91bmQs IEknbSAgc2ltcGx5ICBhbWF6ZWQpIHRha2UgYSBsb29rIDxodHRwOi8vam9obm55LmFjb3VzdGljYnJp YW4uY29tLzMxMzA+DQoNCllvdXJzIGZhaXRoZnVsbHksIENoYXB0ZXIgSVNPQyBDaGFwdGVyIFN1cHBv cnQNCg0KDQoNCkZyb206IEZyZWVCU0QgRmlsZXN5c3RlbXMgW21haWx0bzpmcmVlYnNkLWZzQGZyZWVi c2Qub3JnXQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMjAsIDIwMTYgNDoyOSBQTQ0KVG86IGxpdmVq b3VybmFsQGJla3JleWV2LnJ1DQpTdWJqZWN0OiBJbmNvbXBldGVuY2U/DQoNCkxldCdzIGp1c3QgaW5z dGlsbCAgY29tbXVuaXN0IHJlZGRpdC4gVGhhdCdzICBzbWFydC4gQnV0IHNlcmlvdXNseSB0aGlzIGd1 eSAgZGlkICBpdCBpbiBhIHNjdW1teSB3YXkgYnV0ICBnZXR0aW5nIGEgc21hbGwga2lja2JhY2sgZm9y IHBhcnRzIHRoYXQgeW91IGFjdHVhbGx5IGhhdmUgaXNuJ3QgaW5oZXJlbnRseSBiYWQuICBJIGNhbiBh Z3JlZSB0aGF0IHRoaXMgZ3V5IGRpZCAgaXQgaW4gYSAgd2F5IHRoYXQgaXMgYnJpbmdpbmcgdGhlICBj b21tdW5pdHkgZG93biBidXQgbm90IHRoYXQgaXQgY2FuIG91ciAgc2hvdWxkIG5vdCBiZSBkb25lLg0K DQoNCg== From owner-freebsd-fs@freebsd.org Wed Dec 21 00:28:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 616A8C8ABB4 for ; Wed, 21 Dec 2016 00:28:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0087.outbound.protection.outlook.com [104.47.42.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A62B1764; Wed, 21 Dec 2016 00:28:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 00:12:24 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 00:12:24 +0000 From: Rick Macklem To: Don Lewis CC: "cperciva@tarsnap.com" , "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wSAAJ6iAIABFdOM Date: Wed, 21 Dec 2016 00:12:24 +0000 Message-ID: References: , <201612200715.uBK7FAlL002072@gw.catspoiler.org> In-Reply-To: <201612200715.uBK7FAlL002072@gw.catspoiler.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 05ef0d6a-fd79-4a86-6336-08d429360a62 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:fTWlbPi1CbaetINBOMe77y1P5qzCEnJGeSXSmtdAIlcAKRcwLWxFWsQJeBrbf2pkUTslZQPz/bWLwDuV0c1rV5Y+2OrMqYI3rxk5OK3ixQmXQuENXmmvaKqxqvYkrwJOaEZNFYLFltupv6ChOCCd50Wi99/9ApIJaWXKBtbwt5XwekbCQS13a3LG72olwiEl8VqEheJBnOm+3w+JPyDo8DRLWav1HTYzu11vm3SEi5nrQsQZHmDafhE/8z9SbDuqXHgsLACr9bAVtYB2uXFfE1FG8VU+njNyyeWkysm3AtUZqn/RmQO+oZ9Al4MBUKnOsqSVTXwWfQxByrpP4KDdkHbzvS1Z568Ez4OipEdKUX4wuJyaHMvdiTgQL87UuUs1v1+93zouOVM0Gizcr6SieDVBbNrgUFf14XLdSeddnsOMEfX73P/izLfx893tHG4g4cUOjesJVYsX0WWdP3NTRQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(105586002)(106116001)(97736004)(74482002)(189998001)(122556002)(54356999)(7696004)(110136003)(2950100002)(33656002)(50986999)(76176999)(5660300001)(86362001)(101416001)(8676002)(74316002)(6916009)(92566002)(8936002)(2900100001)(4326007)(305945005)(106356001)(229853002)(38730400001)(9686002)(102836003)(81156014)(3280700002)(6506006)(3660700001)(2906002)(68736007)(77096006)(6436002)(81166006)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 21 Dec 2016 00:12:24.2993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 00:28:10 -0000 Don Lewis wrote: On 19 Dec, Rick Macklem wrote: > Colin Percival wrote: > >>On 12/16/16 12:14, Colin Percival wrote: >>> making this change in nfs_lookup >>>> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >>>> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >>>> @@ -1144,7 +1144,7 @@ >>>> *vpp =3D NULLVP; >>>> } >>>> >>>> - if (error !=3D ENOENT) { >>>> + if (error !=3D ENOENT && error !=3D ESTALE) { >>>> if (NFS_ISV4(dvp)) >>>> error =3D nfscl_maperr(td, error, (uid= _t)0, >>>> (gid_t)0); >>> >>> fixes the case I described above (for some definition of "fixes" -- I'm= not >>> sure if this is the correct way of handling ESTALE here?) but I'm still= seeing >>> ESTALEs from buildworld's cleandir so I think there must be some other = place >>> where something odd is happening. >> >>Further information: In addition to the "lookup relative to a directory w= hich >>has been deleted out from underneath us" case which causes ESTALE to land= in >>nfs_lookup, the cleandir step of buildworld results in ESTALE being retur= ned >>by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ES= TALE >>being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimat= ely >>in stat and lstat). >> >>In UFS there are checks for effnlink =3D=3D 0 which result in e.g. ufs_lo= okup >>returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n= _flag >>and check this in the appropriate nfs_* calls? > To be honest, I can't think of a reason why userland would ever want to s= ee ESTALE? > The function you see above "nfscl_maperr()" could easily map all ESTALEs = to ENOENTs? > - The question is: "Would returning ENOENT for stat(2) and access(2) actu= ally make the > buildworld happy? > if Yes > - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx(= ) calls. > else > - I don't see any point in returning a different error and the= re might be some > code out there somewhere that depends on seeing ESTALE (I do= ubt it, but???). > > The real problem here is that the directory has a reference count on it w= hen it is > rmdir'd. POSIX file systems keep the data until the reference count goes = to 0, but > NFS isn't POSIX. > --> The cheat for regular files is "sillyrename". This could be done for = directories, > but there are multiple comments in the code (not put there by me) t= hat say > "no sillyrename for directories". > #1 Does this imply something breaks when you do sillyrename for dirs= ? > OR > #2 Does it mean no one has bothered to implement it? > Since implementing it would have been pretty easy, I have to suspect #1, = which > means I would be reluctant to do it, at least by default. > --> Maybe I'll send you a patch that does sillyrename for dirs which you = can test. > If it fixes buildworld, then it could be considered for head as a n= on-default option? > >Sillyrename makes sense for files because you can continue to read and >write to a file after it is unlinked, until it is closed and it totally >vanishes. It doesn't make sense for directories since you can't rmdir() >a directory until it is empty. Once it is rmdir()ed, then you can't >create any new entries in the directory because that would mean that you >are creating a disconnnected subtree in the filesystem. Good points. I just tried this ("rm -r" while another process's home dir is= in the subtree) and the process can still "ls" (gets no entries), but can't "cd .." because= that doesn't exist and no process can "cd" into the subtree. --> I can't think of an easy way to make this happen for the NFS client. My hunch is that the failure in "buildworld" will just have to be a "sorry,= but an NFS client isn't POSIX compliant, so this doesn't work" case. Fyi, the only way to safely delete all entries in an NFS mounted dir is: opendir() while (readdir() !=3D EOF) { unlink() the first dir entry acquired by the readdir() closedir() opendir() } So that it is always doing a readdir()/unlink() of the first entry in the d= irectory until the directory is empty. This has always been the case, so I am surprised that "rm -r subdir" usuall= y works.;-) - This is because there is no guarantee that directory offset cookies won't= change when an entry in the directory is removed. - It happens that UFS like file systems did have this property for a lon= g time. (This changed for FreeBSD when r252438 was committed to head, which sk= ipped over the d_ino =3D=3D 0 entries when copying out directories. Howeve= r, UFS still retains the property that the directory offset is monotonically incr= easing and the server can skip ahead to the next entry safely.) - I have no idea whether or not ZFS directory offsets change when an entry = is removed, but I do know that ZFS directory offsets are not monotonically increasing= values. The handling of directories has always been a weak spot for NFS, rick From owner-freebsd-fs@freebsd.org Wed Dec 21 00:42:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 357EDC88042 for ; Wed, 21 Dec 2016 00:42:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0054.outbound.protection.outlook.com [104.47.38.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6D291FBA; Wed, 21 Dec 2016 00:42:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 00:42:21 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 00:42:21 +0000 From: Rick Macklem To: Don Lewis CC: "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wSAAJ6iAIABFdOMgAAOEXw= Date: Wed, 21 Dec 2016 00:42:21 +0000 Message-ID: References: , <201612200715.uBK7FAlL002072@gw.catspoiler.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 55f641cc-4324-41cb-2923-08d4293a3984 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:xuOAh5mDCmbpWYFAb1oK3Suuq/AMFQpvKZwXw4XvlTAZWSs7SokXHUbAWDohgRl1fQDOsUMUoLU/lwgoaLlsWXtPPqzmeTvbvbre4r6ZaCWPgyEGEi1yqSJ110CfrHpLPDDnSPZNwjCKXWlUIPGSqGkRDzRO2dvmm6zINsxrolha6nWK29gdg0+eB9qvP+IbzteHalDnZPOczzyG3lbnDGk7c9KIeE9SHmwLcbnsjU5kBivocQaYLMBG0gjKKxn0trwuPLwb7c3uji1YCyOoA/Rk7QN6r42qR7ybuKuRsPn955jwsq3B0TH+YHoSguNarnwP7n21codxZlw6G1vXlhQKAFDQpyHg4FanmeAncPdwUBbzdh9zVYBZzjP5QOE27sKYGlgTzi8qc2AJF8o4hch0wkuzG0m4g2GInwA4VXPJhA/OOSgEdCMHJjfdurqLs33VF0U2rFiMk5tbL1ytnQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(75325880899374); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377454003)(189002)(199003)(6506006)(74316002)(229853002)(77096006)(102836003)(38730400001)(6436002)(305945005)(9686002)(68736007)(8936002)(50986999)(8676002)(81166006)(81156014)(86362001)(5660300001)(2950100002)(110136003)(7696004)(76176999)(6916009)(4326007)(2906002)(3660700001)(54356999)(101416001)(3280700002)(97736004)(2900100001)(122556002)(92566002)(189998001)(450100001)(33656002)(74482002)(106356001)(106116001)(105586002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2016 00:42:21.4596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 00:42:30 -0000 Oh, I've thought of another reason to not do sillyrename for dirs. Doing this would cause the "rmdir" fail with ENOTEMPTY and that would definitely break things. rick ________________________________________ From: owner-freebsd-fs@freebsd.org on behalf= of Rick Macklem Sent: Tuesday, December 20, 2016 7:12:24 PM To: Don Lewis Cc: freebsd-fs@freebsd.org Subject: Re: ESTALE after cwd deleted by same NFS client Don Lewis wrote: On 19 Dec, Rick Macklem wrote: > Colin Percival wrote: > >>On 12/16/16 12:14, Colin Percival wrote: >>> making this change in nfs_lookup >>>> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >>>> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >>>> @@ -1144,7 +1144,7 @@ >>>> *vpp =3D NULLVP; >>>> } >>>> >>>> - if (error !=3D ENOENT) { >>>> + if (error !=3D ENOENT && error !=3D ESTALE) { >>>> if (NFS_ISV4(dvp)) >>>> error =3D nfscl_maperr(td, error, (uid= _t)0, >>>> (gid_t)0); >>> >>> fixes the case I described above (for some definition of "fixes" -- I'm= not >>> sure if this is the correct way of handling ESTALE here?) but I'm still= seeing >>> ESTALEs from buildworld's cleandir so I think there must be some other = place >>> where something odd is happening. >> >>Further information: In addition to the "lookup relative to a directory w= hich >>has been deleted out from underneath us" case which causes ESTALE to land= in >>nfs_lookup, the cleandir step of buildworld results in ESTALE being retur= ned >>by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ES= TALE >>being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimat= ely >>in stat and lstat). >> >>In UFS there are checks for effnlink =3D=3D 0 which result in e.g. ufs_lo= okup >>returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n= _flag >>and check this in the appropriate nfs_* calls? > To be honest, I can't think of a reason why userland would ever want to s= ee ESTALE? > The function you see above "nfscl_maperr()" could easily map all ESTALEs = to ENOENTs? > - The question is: "Would returning ENOENT for stat(2) and access(2) actu= ally make the > buildworld happy? > if Yes > - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx(= ) calls. > else > - I don't see any point in returning a different error and the= re might be some > code out there somewhere that depends on seeing ESTALE (I do= ubt it, but???). > > The real problem here is that the directory has a reference count on it w= hen it is > rmdir'd. POSIX file systems keep the data until the reference count goes = to 0, but > NFS isn't POSIX. > --> The cheat for regular files is "sillyrename". This could be done for = directories, > but there are multiple comments in the code (not put there by me) t= hat say > "no sillyrename for directories". > #1 Does this imply something breaks when you do sillyrename for dirs= ? > OR > #2 Does it mean no one has bothered to implement it? > Since implementing it would have been pretty easy, I have to suspect #1, = which > means I would be reluctant to do it, at least by default. > --> Maybe I'll send you a patch that does sillyrename for dirs which you = can test. > If it fixes buildworld, then it could be considered for head as a n= on-default option? > >Sillyrename makes sense for files because you can continue to read and >write to a file after it is unlinked, until it is closed and it totally >vanishes. It doesn't make sense for directories since you can't rmdir() >a directory until it is empty. Once it is rmdir()ed, then you can't >create any new entries in the directory because that would mean that you >are creating a disconnnected subtree in the filesystem. Good points. I just tried this ("rm -r" while another process's home dir is= in the subtree) and the process can still "ls" (gets no entries), but can't "cd .." because= that doesn't exist and no process can "cd" into the subtree. --> I can't think of an easy way to make this happen for the NFS client. My hunch is that the failure in "buildworld" will just have to be a "sorry,= but an NFS client isn't POSIX compliant, so this doesn't work" case. Fyi, the only way to safely delete all entries in an NFS mounted dir is: opendir() while (readdir() !=3D EOF) { unlink() the first dir entry acquired by the readdir() closedir() opendir() } So that it is always doing a readdir()/unlink() of the first entry in the d= irectory until the directory is empty. This has always been the case, so I am surprised that "rm -r subdir" usuall= y works.;-) - This is because there is no guarantee that directory offset cookies won't= change when an entry in the directory is removed. - It happens that UFS like file systems did have this property for a lon= g time. (This changed for FreeBSD when r252438 was committed to head, which sk= ipped over the d_ino =3D=3D 0 entries when copying out directories. Howeve= r, UFS still retains the property that the directory offset is monotonically incr= easing and the server can skip ahead to the next entry safely.) - I have no idea whether or not ZFS directory offsets change when an entry = is removed, but I do know that ZFS directory offsets are not monotonically increasing= values. The handling of directories has always been a weak spot for NFS, rick _______________________________________________ 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 Wed Dec 21 03:25:41 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D1FCC8A2DE for ; Wed, 21 Dec 2016 03:25:41 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB8F117EE for ; Wed, 21 Dec 2016 03:25:40 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id uBL3PVtg006345; Tue, 20 Dec 2016 19:25:36 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201612210325.uBL3PVtg006345@gw.catspoiler.org> Date: Tue, 20 Dec 2016 19:25:31 -0800 (PST) From: Don Lewis Subject: Re: ESTALE after cwd deleted by same NFS client To: rmacklem@uoguelph.ca cc: cperciva@tarsnap.com, freebsd-fs@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 03:25:41 -0000 On 21 Dec, Rick Macklem wrote: > Don Lewis wrote: > > On 19 Dec, Rick Macklem wrote: >> Colin Percival wrote: >> >>>On 12/16/16 12:14, Colin Percival wrote: >>>> making this change in nfs_lookup >>>>> --- sys/fs/nfsclient/nfs_clvnops.c (revision 310132) >>>>> +++ sys/fs/nfsclient/nfs_clvnops.c (working copy) >>>>> @@ -1144,7 +1144,7 @@ >>>>> *vpp = NULLVP; >>>>> } >>>>> >>>>> - if (error != ENOENT) { >>>>> + if (error != ENOENT && error != ESTALE) { >>>>> if (NFS_ISV4(dvp)) >>>>> error = nfscl_maperr(td, error, (uid_t)0, >>>>> (gid_t)0); >>>> >>>> fixes the case I described above (for some definition of "fixes" -- I'm not >>>> sure if this is the correct way of handling ESTALE here?) but I'm still seeing >>>> ESTALEs from buildworld's cleandir so I think there must be some other place >>>> where something odd is happening. >>> >>>Further information: In addition to the "lookup relative to a directory which >>>has been deleted out from underneath us" case which causes ESTALE to land in >>>nfs_lookup, the cleandir step of buildworld results in ESTALE being returned >>>by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ESTALE >>>being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimately >>>in stat and lstat). >>> >>>In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup >>>returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag >>>and check this in the appropriate nfs_* calls? >> To be honest, I can't think of a reason why userland would ever want to see ESTALE? >> The function you see above "nfscl_maperr()" could easily map all ESTALEs to ENOENTs? >> - The question is: "Would returning ENOENT for stat(2) and access(2) actually make the >> buildworld happy? >> if Yes >> - then mapping ESTALE->ENOENT makes sense for most/all VOP_xxx() calls. >> else >> - I don't see any point in returning a different error and there might be some >> code out there somewhere that depends on seeing ESTALE (I doubt it, but???). >> >> The real problem here is that the directory has a reference count on it when it is >> rmdir'd. POSIX file systems keep the data until the reference count goes to 0, but >> NFS isn't POSIX. >> --> The cheat for regular files is "sillyrename". This could be done for directories, >> but there are multiple comments in the code (not put there by me) that say >> "no sillyrename for directories". >> #1 Does this imply something breaks when you do sillyrename for dirs? >> OR >> #2 Does it mean no one has bothered to implement it? >> Since implementing it would have been pretty easy, I have to suspect #1, which >> means I would be reluctant to do it, at least by default. >> --> Maybe I'll send you a patch that does sillyrename for dirs which you can test. >> If it fixes buildworld, then it could be considered for head as a non-default option? >> >>Sillyrename makes sense for files because you can continue to read and >>write to a file after it is unlinked, until it is closed and it totally >>vanishes. It doesn't make sense for directories since you can't rmdir() >>a directory until it is empty. Once it is rmdir()ed, then you can't >>create any new entries in the directory because that would mean that you >>are creating a disconnnected subtree in the filesystem. > Good points. I just tried this ("rm -r" while another process's home dir is in the subtree) > and the process can still "ls" (gets no entries), but can't "cd .." because that doesn't > exist and no process can "cd" into the subtree. > --> I can't think of an easy way to make this happen for the NFS client. It sort of seems like this should be handled at the vfs level. Once rmdir() succeeds, there should be no calls to the underlying fs code. Maybe add a deleted flag to the vnode ... Dunno how ufs and zfs handle this, but the right thing happens: %mkdir /tmp/barf1 %cd /tmp/barf1 %rmdir /tmp/barf1 %touch barf2 touch: barf2: No such file or directory %ls From owner-freebsd-fs@freebsd.org Wed Dec 21 04:00:47 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE007C8A881 for ; Wed, 21 Dec 2016 04:00:47 +0000 (UTC) (envelope-from 010001591f89c531-9df17b6f-0a7d-421b-89eb-c3bfa8da6b9a-000000@amazonses.com) Received: from a8-176.smtp-out.amazonses.com (a8-176.smtp-out.amazonses.com [54.240.8.176]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9460D1598 for ; Wed, 21 Dec 2016 04:00:46 +0000 (UTC) (envelope-from 010001591f89c531-9df17b6f-0a7d-421b-89eb-c3bfa8da6b9a-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1482292839; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=x+7g5jupKI639KOd9WT/hSrJcQLZtu0/AKGiuM5d1xs=; b=py60HILIRBthrly6176nbUu/qm6cl772DsSo25azwPZnFFDM1ZPhvlfYqK+4URR7 A9CYVtYK2M5AaL0JTabRVy0i/62DotLYmhfYtZ1vS5NBcJf+NtAmkhgHmoZy7q2f4nk byFSLA7fiPMhaE8kHAtvdTqYkOtRQ6Fr3qus2eDY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1482292839; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=x+7g5jupKI639KOd9WT/hSrJcQLZtu0/AKGiuM5d1xs=; b=vG1eEpWEb+1x61Ch7adSq+ti4VxXT8+iqYU3HuV4Ca20zbtexYUS3yZH/kF230Wu o5EcreIAEuYVazuSxRIk4PLBwHrI/EKaZIx8uM/Vy8RLQcZPRQ+AXAerByPRIWkDS+k 8/Pmc1afWHGmbvZT+0XqGKVHmX3dEBcpMit6krGc= Subject: Re: ESTALE after cwd deleted by same NFS client To: Don Lewis , rmacklem@uoguelph.ca References: <201612210325.uBL3PVtg006345@gw.catspoiler.org> Cc: freebsd-fs@freebsd.org From: Colin Percival Message-ID: <010001591f89c531-9df17b6f-0a7d-421b-89eb-c3bfa8da6b9a-000000@email.amazonses.com> Date: Wed, 21 Dec 2016 04:00:39 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <201612210325.uBL3PVtg006345@gw.catspoiler.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.21-54.240.8.176 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 04:00:47 -0000 On 12/20/16 19:25, Don Lewis wrote: >>> Colin Percival wrote: >>>> In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup >>>> returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag >>>> and check this in the appropriate nfs_* calls? > > It sort of seems like this should be handled at the vfs level. Once > rmdir() succeeds, there should be no calls to the underlying fs code. > Maybe add a deleted flag to the vnode ... Or perhaps to the nfsnode, as I suggested a few emails ago? > Dunno how ufs and zfs handle this, but the right thing happens: I haven't looked at ZFS, but in UFS there are checks for effnlink == 0 which result in calls returning ENOENT. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Wed Dec 21 06:24:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 171BAC8AC14; Wed, 21 Dec 2016 06:24:19 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (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 E2BFF1297; Wed, 21 Dec 2016 06:24:18 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.15.2/8.15.2) with ESMTP id uBL6OGbG006929; Wed, 21 Dec 2016 01:24:16 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.15.2/8.14.4/Submit) id uBL6OGsJ006928; Wed, 21 Dec 2016 01:24:16 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22618.8208.273426.702678@hergotha.csail.mit.edu> Date: Wed, 21 Dec 2016 01:24:16 -0500 From: Garrett Wollman To: freebsd-fs@freebsd.org Cc: freebsd-stable@freebsd.org, rmacklem@freebsd.org Subject: NFS server hang with backing store on ZFS and quota nearly exhausted X-Mailer: VM 8.2.0b under 25.1.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.1 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 21 Dec 2016 01:24:17 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 06:24:19 -0000 I've opened a bug about this before, which I can't cite by number because bugzilla appears to be down at the moment. But I had this problem recur tonight under otherwise idle conditions, so I was able to get a set of kernel stacks without any confounding RPC activity going on. This is on 10.2; we're not scheduled to take these servers to 10.3 until next week. Here's the "procstat -kk" output. PID TID COMM TDNAME KSTACK 1055 101965 nfsd - mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a seltdwait+0xae kern_select+0x8fa sys_select+0x54 amd64_syscall+0x357 Xfast_syscall+0xfb 1058 101012 nfsd nfsd: service mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_wait_sig+0xf _cv_wait_sig+0x16a svc_run_internal+0x8be svc_thread_start+0xb fork_exit+0x9a fork_trampoline+0xe [Threads with the stack trace above are simply idle and waiting for incoming requests, and I've deleted the other 5 of them.] 1058 101688 nfsd nfsd: service mi_switch+0xe1 sleepq_catch_signals+0xab sleepq_timedwait_sig+0x10 _cv_timedwait_sig_sbt+0x18b svc_run_internal+0x4bd svc_thread_start+0xb fork_exit+0x9a fork_trampoline+0xe [Not sure what these threads are doing: obviously they are waiting for a condvar, but at a different spot in svc_run_internal(). I've deleted the other 7 of them.] 1058 101720 nfsd nfsd: service mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_wait_open+0x85 dmu_tx_wait+0x2ac dmu_tx_assign+0x48 zfs_freebsd_write+0x544 VOP_WRITE_APV+0x149 nfsvno_write+0x13e nfsrvd_write+0x496 nfsrvd_dorpc+0x6f1 nfssvc_program+0x54e svc_run_internal+0xd7b svc_thread_start+0xb fork_exit+0x9a fork_trampoline+0xe 1058 102015 nfsd nfsd: master mi_switch+0xe1 sleepq_wait+0x3a _cv_wait+0x16d txg_wait_open+0x85 dmu_tx_wait+0x2ac dmu_tx_assign+0x48 zfs_freebsd_write+0x544 VOP_WRITE_APV+0x149 nfsvno_write+0x13e nfsrvd_write+0x496 nfsrvd_dorpc+0x6f1 nfssvc_program+0x54e svc_run_internal+0xd7b svc_run+0x1de nfsrvd_nfsd+0x242 nfssvc_nfsd+0x107 sys_nfssvc+0x9c amd64_syscall+0x357 Then there are these two threads, both servicing WRITE RPCs, both sleeping deep inside the ZFS code. Note that one of them is the "master" krpc thread in this service pool; I don't know if this accounts for the fact that requests are not getting processed even though plenty of idle threads exist. (Note that zfs_write() does not appear in the stack due to tail-call optimization.) I don't know the ZFS code well enough to understand what running out of quota has to do with this situation (you'd think it would just return immediately with [EDQUOT]) but perhaps it matters that the clients are not well-behaved and that the filesystem is often almost at quota but not quite there yet. -GAWollman From owner-freebsd-fs@freebsd.org Wed Dec 21 07:33:19 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2242BC8AE3A; Wed, 21 Dec 2016 07:33:19 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 9E954188B; Wed, 21 Dec 2016 07:33:18 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id g23so28835578wme.1; Tue, 20 Dec 2016 23:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K2uFvCdQLAozHJBveM83HGVGsknGw/9aVU0V5mFw4Fg=; b=kg6f1U9YjVjVrXgOj9Zv9bxkct1bzGmkBjEp2y4K52lml9Bkoluvxjzf78IgfWC6Dn n/syUqlFOcO1ltwfct+kWde2QU1kAPb9pIeOyxoWnTHTsV4IGxGErNtiAGIabuMdhnPy rKH6oHfi5/OAN2EP2x5Qzh2I7ikuOPTQygf42XH867WgIBcOeaa1CM5QR6qwnZkQgGXF iALJzgKA0c+ohm3hABHgcQj+G938WX2Nc5VDV/iUx28URS4A9bzWlNY2v7IJ1xvEdUsJ kOR6s3r2iNKFJG1chh/G0EbSLcotmp9DfVr1y3qjwhwf4GBBoTcUCfwnpYehRytReTRJ IZTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K2uFvCdQLAozHJBveM83HGVGsknGw/9aVU0V5mFw4Fg=; b=YnMq9NYWUGYHHx4BfvQzjtU121u5X/v709/WKlaBtAUZ/rNMeAgGS8zIpj4/6bLsvM t927Rl/FHh6G0oKWMnNfnFwmefOCS415eKa0K7ZSgkE5ik679EIvXvx9U0ZmI+l1pcWH pxJOIZJO7sGsY1B+4qsqfWgM3PAe1l188/Qgp86qUjeS+onMsOlFnTTwY122jQSKXKOc YPJngAu04lwQ8PZIZy/yySCHHSb0Yt2glWinQ+WAcHQTQphIH0GRmgH7pWkir/b1empT kDw6cJG3Z1H1tUmAwBLZovx826p4dOfOakt8efJuNZzqPAQucyBqJIm5daDd79a5GVOY e4IQ== X-Gm-Message-State: AIkVDXLooLk8t7w73XzJbtpmnjaOe5TQP/oFR+D62yPQT4lCL99gi1TKBkejTHlsqwzELg== X-Received: by 10.28.169.74 with SMTP id s71mr5408777wme.1.1482305596948; Tue, 20 Dec 2016 23:33:16 -0800 (PST) Received: from ben.home (LFbn-1-7159-4.w90-116.abo.wanadoo.fr. [90.116.90.4]) by smtp.gmail.com with ESMTPSA id x188sm25622937wmx.4.2016.12.20.23.33.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Dec 2016 23:33:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: NFS server hang with backing store on ZFS and quota nearly exhausted From: Ben RUBSON In-Reply-To: <22618.8208.273426.702678@hergotha.csail.mit.edu> Date: Wed, 21 Dec 2016 08:33:17 +0100 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <22618.8208.273426.702678@hergotha.csail.mit.edu> To: freebsd-fs X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 07:33:19 -0000 > On 21 Dec 2016, at 07:24, Garrett Wollman wrote: > > I don't know the ZFS code well enough to understand what running out > of quota has to do with this situation (you'd think it would just > return immediately with [EDQUOT]) but perhaps it matters that the > clients are not well-behaved and that the filesystem is often almost > at quota but not quite there yet. Hi Garrett, ZFS is slow when your are playing around the quota limit, due to how quota are implemented. See this thread : https://lists.freebsd.org/pipermail/freebsd-fs/2016-September/023874.html Ben From owner-freebsd-fs@freebsd.org Wed Dec 21 10:47:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04386C8A39C for ; Wed, 21 Dec 2016 10:47:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E799D1907 for ; Wed, 21 Dec 2016 10:47:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLAl9Vs058180 for ; Wed, 21 Dec 2016 10:47:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 10:47:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: m.r.sopacua@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 10:47:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #3 from Melvyn Sopacua --- I have several nodes all using /dev/fuse, but I'm using an rc.d script to mount/unmount them, which is run by root. My unmounting part is this: ntfsmount_unmount() { # We can't check this, since mount -p with path argument only checks # nodes in fstab(5). # if /sbin/mount -p ${ntfsmount_mountpoint} >/dev/null 2>&1 # So we need to envoke mount -p without argument and grep for the # mountpoint instead. if check_is_mounted ${ntfsmount_mountpoint} then /sbin/umount ${ntfsmount_mountpoint} fi } check_is_mounted() { local mp is_mounted mp=3D"$1" is_mounted=3D`/sbin/mount -p|sed -ne "s,^/dev/fuse.*[[:space:]]\(${mp}\)[[:space:]].*$,\\1,p"` if [ ! -z "${is_mounted}" -a x"${is_mounted}" =3D x"${mp}" ] then return 0 fi return 1 } This does the right thing for me. As for the code you've shown, it seems li= ke a bug to use fstat, as you can never get the path it is mounted *on* from tha= t. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 11:05:37 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86BCFC8A894 for ; Wed, 21 Dec 2016 11:05:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 704841240 for ; Wed, 21 Dec 2016 11:05:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLB5bhV042332 for ; Wed, 21 Dec 2016 11:05:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 11:05:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ben.rubson@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 11:05:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #4 from Ben RUBSON --- Thank you for your feedback Melvyn ! What do the following command return when you have several fuse mounted ? ls -l /dev/fuse* fstat /dev/fuse* uname -a Thank you again ! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 11:06:21 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0247C8A944 for ; Wed, 21 Dec 2016 11:06:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF803136D for ; Wed, 21 Dec 2016 11:06:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLB6LDL043854 for ; Wed, 21 Dec 2016 11:06:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 11:06:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ben.rubson@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 11:06:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #5 from Ben RUBSON --- Well uname -r is enough :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 14:39:18 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 952B4C8A94A for ; Wed, 21 Dec 2016 14:39:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829BB153F for ; Wed, 21 Dec 2016 14:39:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLEdIv0095226 for ; Wed, 21 Dec 2016 14:39:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 14:39:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: martin@lispworks.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 14:39:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 martin@lispworks.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin@lispworks.com --- Comment #6 from martin@lispworks.com --- (In reply to Ben RUBSON from comment #0) What is calling fuse_unmount_compat22? I think newly compiled code should end up calling fuse_kern_unmount, which should be fixed by files/patch-lib_mount_bsd.c. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 16:01:09 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CCF9C8AC83 for ; Wed, 21 Dec 2016 16:01:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F06DF1666 for ; Wed, 21 Dec 2016 16:01:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLG18kL080355 for ; Wed, 21 Dec 2016 16:01:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 16:01:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ben.rubson@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 16:01:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #7 from Ben RUBSON --- encfs is calling fuse_unmount_compat22 : https://github.com/vgough/encfs/blob/v1.9.1/encfs/main.cpp#L48 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 16:05:17 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 916F9C8AF57 for ; Wed, 21 Dec 2016 16:05:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8062C1A89 for ; Wed, 21 Dec 2016 16:05:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLG5HeC013008 for ; Wed, 21 Dec 2016 16:05:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 16:05:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: m.r.sopacua@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 16:05:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #8 from Melvyn Sopacua --- (In reply to Ben RUBSON from comment #4) ls -l /dev/fuse* crw-rw---- 1 root staff 0x3a Dec 21 16:58 /dev/fuse sudo fstat /dev/fuse USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root ntfs-3g 1272 4 /dev 58 crw-rw---- fuse rw /dev/= fuse root ntfs-3g 1255 4 /dev 58 crw-rw---- fuse rw /dev/= fuse % mount -p|grep '^/dev/fuse' /dev/fuse /home/melvyn/Music/Windisk fusefs ro,sync=20= =20=20=20=20=20=20 0 0 /dev/fuse /home/melvyn/win7 fusefs ro,sync 0 0 % pkg query '%n-%v' sysutils/fusefs-libs fusefs-libs-2.9.5 % uname -r 10.3-RELEASE-p12 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Wed Dec 21 20:34:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2BF1C8AC11 for ; Wed, 21 Dec 2016 20:34:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2299104A for ; Wed, 21 Dec 2016 20:34:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBLKYAJQ026174 for ; Wed, 21 Dec 2016 20:34:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node Date: Wed, 21 Dec 2016 20:34:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: martin@lispworks.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 20:34:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212318 --- Comment #9 from martin@lispworks.com --- (In reply to Ben RUBSON from comment #7) Yuck, looks like fuse_unmount_compat22 needs to be patched to just call unmount(mountpoint, MNT_FORCE) as well then. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Thu Dec 22 00:24:43 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3738C8B8AE for ; Thu, 22 Dec 2016 00:24:43 +0000 (UTC) (envelope-from 0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@amazonses.com) Received: from a8-56.smtp-out.amazonses.com (a8-56.smtp-out.amazonses.com [54.240.8.56]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88663886 for ; Thu, 22 Dec 2016 00:24:43 +0000 (UTC) (envelope-from 0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=vnqrkfnvu6csdl6mwgk5t6ix3nnepx57; d=tarsnap.com; t=1482366281; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=7DfO7d+zmjsQdoq78KnYEN989hSCpuqrcpKj7eTlPog=; b=Lt0JjQucLSGFSSdrW3YxFMykoKcM5PaoJ2ef+vo9uwVIaw9JQESkPz1kqz7mZdvZ aupDNBNfL5LmlChPzamaBKp5gv0wIPFMQOflAlccNj0Rj/d7DkMkHExajCyQg8H3G0L HmXrvIeHq/+fcPVP9s9V4Q3MR7thEMGPauA30pVo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1482366281; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=7DfO7d+zmjsQdoq78KnYEN989hSCpuqrcpKj7eTlPog=; b=CSSc10195gymr4viDdIiRBrI77pohYd3bugWo4RYftUfR7RSXMg5Q30fMLQFWGy2 bFgGgNgIRa5J66HyGf/Q0WCCVBgsJkBPyF4zmQA6KxWfakTqjkQc61O4OFB8XTeM6gT EDlwX1Bw2LtWS/qodwiX6/DAJYnLgwWpnD8VLziA= Subject: Re: ESTALE after cwd deleted by same NFS client To: Rick Macklem , Don Lewis References: <201612210325.uBL3PVtg006345@gw.catspoiler.org> <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> Cc: "freebsd-fs@freebsd.org" From: Colin Percival Message-ID: <0100015923ea6593-aab9a22e-3bce-466a-9608-b2c29bf6f26c-000000@email.amazonses.com> Date: Thu, 22 Dec 2016 00:24:41 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SES-Outgoing: 2016.12.22-54.240.8.56 Feedback-ID: 1.us-east-1.Lv9FVjaNvvR5llaqfLoOVbo2VxOELl7cjN0AOyXnPlk=:AmazonSES X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 00:24:43 -0000 On 12/21/16 14:43, Rick Macklem wrote: >> On 12/20/16 19:25, Don Lewis wrote: >>> It sort of seems like this should be handled at the vfs level. Once >>> rmdir() succeeds, there should be no calls to the underlying fs code. >>> Maybe add a deleted flag to the vnode ... >> > As I already mentioned to Colin, there is also the case where another client did the > "rmdir" and the ESTALE will happen for that case, so mapping ESTALE->ENOENT > seems to me to be a simple (and maybe more general) solution for NFS. Except that ENOENT means "the named file does not exist", and ESTALE simply means "the file which had that name a while ago no longer exists". If you have one machine which calls open("foo") and another machine which calls rename("bar", "foo") then you can very reasonably expect to not get ENOENT. It seems to me that "behave like a local filesystem with respect to other operations from the same client, but return ESTALE if a different client rips files/directories out from underneath you" makes more sense than having ENOENT get returned when there is in fact a file with the specified name. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-fs@freebsd.org Thu Dec 22 01:16:17 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08912C8ADD8 for ; Thu, 22 Dec 2016 01:16:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0052.outbound.protection.outlook.com [104.47.38.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A676122D; Thu, 22 Dec 2016 01:16:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 22:43:27 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 22:43:27 +0000 From: Rick Macklem To: Colin Percival , Don Lewis CC: "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wSAAJ6iAIABFdOMgAA8WICAAAnSAIABOPDS Date: Wed, 21 Dec 2016 22:43:27 +0000 Message-ID: References: <201612210325.uBL3PVtg006345@gw.catspoiler.org>, <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> In-Reply-To: <010001591f89c80b-c8ffef86-2b96-4e3f-98c9-59410b0c796a-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 57217a5b-6c0b-4c82-7966-08d429f2c7da x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0190; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:3tHAR1VMsCqP3qvrcz36P5kyEewA/VFRcm4iF5AWufbiYsjC92d1+pSeA/Y0xptaqv8/dICWmaLDuVW6EVT5MkKjjBmYWLu4sa1FEkF3CwoQYD2D5zlIbkGRY0fjyVsXoauUE5BX4X66wGsF4yhyJCvE1e4ly4wxTxGsrgWTYtWsBQJBFbyllvQMOef2VHpoihhsL4LKN2s5uEzlCBdlbJzBX5i+qFmCq3mGGQbhVZNAfOcRE8swUADnQdwutALrXLjEKhcHc2Zn5VjAV+HV6lH44KvwKB7FhwhTwoxqoOxTeQkeUCkreQ1tPc6+FlnD54iwsj2H6UCdkIZHPPnE+xjf8FnDdqdRIjrlnH0ALnBgYrySN/XFD2lSr1OLIFy9Ugmwr5Kx431PsxL5B5c07YEkprhU4lxNeUXOX5SWjTRTcK+b7oaS7N/RYeh72WnV9lX7+HiYl04lGt2w0fNnoQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0190; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(54356999)(229853002)(122556002)(92566002)(74316002)(305945005)(106356001)(102836003)(105586002)(8676002)(2900100001)(9686002)(106116001)(8936002)(81156014)(81166006)(68736007)(6506006)(38730400001)(86362001)(101416001)(77096006)(33656002)(6436002)(2906002)(74482002)(4326007)(3660700001)(97736004)(5660300001)(189998001)(5001770100001)(7696004)(3280700002)(50986999)(2950100002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 21 Dec 2016 22:43:27.5348 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 01:16:17 -0000 Colin Percival wrote: >On 12/20/16 19:25, Don Lewis wrote: >>>> Colin Percival wrote: >>>>> In UFS there are checks for effnlink =3D=3D 0 which result in e.g. uf= s_lookup >>>>> returning ENOENT; would it make sense to add NREMOVED to struct nfsno= de.n_flag >>>>> and check this in the appropriate nfs_* calls? >> >> It sort of seems like this should be handled at the vfs level. Once >> rmdir() succeeds, there should be no calls to the underlying fs code. >> Maybe add a deleted flag to the vnode ... > >Or perhaps to the nfsnode, as I suggested a few emails ago? > >> Dunno how ufs and zfs handle this, but the right thing happens: > >I haven't looked at ZFS, but in UFS there are checks for effnlink =3D=3D 0= which >result in calls returning ENOENT. As I already mentioned to Colin, there is also the case where another clien= t did the "rmdir" and the ESTALE will happen for that case, so mapping ESTALE->ENOENT seems to me to be a simple (and maybe more general) solution for NFS. rick From owner-freebsd-fs@freebsd.org Thu Dec 22 01:27:24 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1A28C8BAAA for ; Thu, 22 Dec 2016 01:27:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0059.outbound.protection.outlook.com [104.47.41.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB0F9D7A; Thu, 22 Dec 2016 01:27:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 21 Dec 2016 23:52:59 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0789.018; Wed, 21 Dec 2016 23:52:59 +0000 From: Rick Macklem To: Don Lewis CC: "cperciva@tarsnap.com" , "freebsd-fs@freebsd.org" Subject: Re: ESTALE after cwd deleted by same NFS client Thread-Topic: ESTALE after cwd deleted by same NFS client Thread-Index: AQHSVANFVKFixagVOUGZ8mLDXQwbl6EDzQuAgAC4aM2AAVLGrIABN7mAgABdEGCAAjtv0oAFKIhagAEJ9wSAAJ6iAIABFdOMgAA8WICAAVBkMg== Date: Wed, 21 Dec 2016 23:52:59 +0000 Message-ID: References: , <201612210325.uBL3PVtg006345@gw.catspoiler.org> In-Reply-To: <201612210325.uBL3PVtg006345@gw.catspoiler.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: a69b3b2c-aae7-47f6-7996-08d429fc7e88 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:9XtLcnJV16sHMG3chPvjNElszB8vHLEZOBXXwVLW56+D1OEvx9kaxAaGTqW6CFAhjFkFXk4t0BMLpU02eeexEYAM4CNgSatnGFKVV07fuJOeqXZPBPgKWiBNgJHkOreAe6PFdPbvverDiLNsnKkTUKlsepvRmrCc0zCIv+s9rj+XxMWKzWfaFj2cN1N1h2zMlkir4d3pqfTcdtugS8iKlq6JEg3yuDKCtHThjoSU6UGJXreyAHXw6C3xbUM1+JnfSbsFD+wOwf/vd8xZoIwuwNbgRY5K8ECGWtI67ajU5RhatoS1OCdZBdSuWQhPxz9DWAyK18sjcQUrZq8zVqo0SIaA7uQKD18M0YYBNaGt70m40sCbmC6ba5J2mPNfVfqr4pat7QSpFcL8DfHm0lBIYoRuCpHeZtqedrmtK6U9xHAENhQ7pK9uvSqWvOkaI/OuY+9oWNbt/0C4c5Gk0+hdxA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(24454002)(199003)(77096006)(6436002)(8936002)(8676002)(92566002)(2906002)(305945005)(81156014)(81166006)(229853002)(38730400001)(105586002)(2900100001)(54356999)(122556002)(76176999)(74482002)(68736007)(106356001)(9686002)(3280700002)(102836003)(50986999)(6506006)(3660700001)(106116001)(101416001)(110136003)(2950100002)(6916009)(97736004)(7696004)(5660300001)(33656002)(4326007)(86362001)(74316002)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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-originalarrivaltime: 21 Dec 2016 23:52:59.6292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 01:27:25 -0000 Don Lewis wrote: [stuff snipped] > Dunno how ufs and zfs handle this, but the right thing happens: > > %mkdir /tmp/barf1 > %cd /tmp/barf1 > %rmdir /tmp/barf1 > %touch barf2 > touch: barf2: No such file or directory > %ls I tried this as "root" (the only user that matters;-) on a UFS file system = and got the above, but also observed a couple of interesting things: 1 - "ls -a" returned without showing "." or "..". 2 - "cat -v ." worked and showed a directory block with "." and ".." in it. The entries looked valid and did not have d_fileno =3D=3D 0. If root does a getdents() it returns a 0 reply instead of the directory blo= ck with "." and ".." in it. I think this explains why "ls -a" shows nothing, b= ut does not see an error. (getdents() would return -1 for an error, but it returns = 0 for EOF on the directory.) I suppose that nfs_readdir() could fake #1 by just returning without an err= or (ie no data) when it gets ESTALE. I don't think support of #2 is required? Not a POSIX guy, so I don't know what POSIX defines/expects for this case? rick From owner-freebsd-fs@freebsd.org Thu Dec 22 13:05:51 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E21DC8C7B9 for ; Thu, 22 Dec 2016 13:05:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6DE09885 for ; Thu, 22 Dec 2016 13:05:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBMD5mqZ064104 for ; Thu, 22 Dec 2016 13:05:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 209158] node / npm triggering zfs rename deadlock Date: Thu, 22 Dec 2016 13:05:49 +0000 X-Bugzilla-Reason: CC 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: needs-qa, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: paul@ifdnrg.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: avg@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 13:05:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209158 paul@ifdnrg.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul@ifdnrg.com --- Comment #48 from paul@ifdnrg.com --- I believe i am seeing activity related to this PR We're finding that npm gets stuck in updates, and if the parent is=20 killed, it leaves a process in uninterruptible state (this has not even been killlable during shutdown and a previous box=20 with same symptoms has needed a hard reset) Child processes get stuck in a DN state, it does not seem to matter if npm = or node was running prior to update, as npm is called as part of the update process. This also seems to be affecting separate periodic scripts such as 100.check= suid which also become stuck. We now have 5 boxes in this state, and i suspect all will need a hard reboo= t to clear. Systems are FreeBSD 10.3-REL on ZFS --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Thu Dec 22 14:31:32 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90140C8B3DB for ; Thu, 22 Dec 2016 14:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 716066AE for ; Thu, 22 Dec 2016 14:31:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBMEVUj8094296 for ; Thu, 22 Dec 2016 14:31:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 199189] SWAP on ZFS can crash server Date: Thu, 22 Dec 2016 14:31: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: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: scottro11@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:31:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D199189 scottro11@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scottro11@gmail.com --- Comment #22 from scottro11@gmail.com --- So, does anyone know if the tuning is still necessary? I am not a coder and looking at the source code won't really help me. If anyone has tested recently, I'd be grateful for them sharing their knowledge. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Dec 23 16:40:03 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EE6EC8E229 for ; Fri, 23 Dec 2016 16:40: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 mx1.freebsd.org (Postfix) with ESMTPS id F251B1789 for ; Fri, 23 Dec 2016 16:40:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id uBNGe2ZQ019744 for ; Fri, 23 Dec 2016 16:40:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 215519] [fusefs] strange issue when glusterfs is fuse mounted, files not handled as expected. Date: Fri, 23 Dec 2016 16:40:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 16:40:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215519 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.=