From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753244AbbE1Mzq (ORCPT ); Thu, 28 May 2015 08:55:46 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:34273 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbbE1Mzg (ORCPT ); Thu, 28 May 2015 08:55:36 -0400 Message-ID: <55671036.9070607@gmail.com> Date: Thu, 28 May 2015 08:55:18 -0400 From: Austin S Hemmelgarn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Phillips , Pavel Machek CC: linux-fsdevel@vger.kernel.org, tux3@tux3.org, Mosis Tembo , linux-kernel@vger.kernel.org, OGAWA Hirofumi Subject: Re: Tux3 Report: How fast can we fail? References: <8f886f13-6550-4322-95be-93244ae61045@phunq.net> <55523C88.9080809@phunq.net> <20150526100326.GA8854@amd> <20150527213952.GB15721@amd> <55664943.7030201@phunq.net> In-Reply-To: <55664943.7030201@phunq.net> x-hashcash: 1:21:150528:daniel@phunq.net::5fe247694b52d2b3da478d273e54ed12:6ce4c8935548ab0a x-hashcash: 1:21:150528:pavel@ucw.cz::b441ca36e664d9d7b3ebf5b878c6b745:8fd2337fce3371c3 x-hashcash: 1:21:150528:linux-fsdevel@vger.kernel.org::dba3e5dfd09496364bd63881c88b9583:dac0ed5ffff31440 x-hashcash: 1:21:150528:tux3@tux3.org::f34a6661a684be2baa1a0c2eb46aae88:39ee920b3c662f02 x-hashcash: 1:21:150528:mosis.tembo@gmail.com::ff692cfad17aad691b7f7dd17483a676:7aa0a22bd0b3df52 x-hashcash: 1:21:150528:linux-kernel@vger.kernel.org::7b764168aea18250b05c545c39101271:66fb6c2fa61ee195 x-hashcash: 1:21:150528:hirofumi@mail.parknet.co.jp::db3d937fe727b8147e58018765651de6:dcac4f5b20ac0d9d x-stampprotocols: hashcash:1:17;mbound:0:10:3000:5000 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070607090509050706070201" X-Antivirus: avast! (VPS 150528-0, 2015-05-28), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a cryptographically signed message in MIME format. --------------ms070607090509050706070201 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-05-27 18:46, Daniel Phillips wrote: > > > On 05/27/2015 02:39 PM, Pavel Machek wrote: >> On Wed 2015-05-27 11:28:50, Daniel Phillips wrote: >>> On Tuesday, May 26, 2015 11:41:39 PM PDT, Mosis Tembo wrote: >>>> On Tue, May 26, 2015 at 6:03 PM, Pavel Machek wrote: >>>> >>>>> >>>>>> We identified the following quality metrics for this algorithm: >>>>>> >>>>>> 1) Never fails to detect out of space in the front end. >>>>>> 2) Always fills a volume to 100% before reporting out of space. >>>>>> 3) Allows rm, rmdir and truncate even when a volume is full. >>>> >>>> This is definitely nonsense. You can not rm, rmdir and truncate >>>> when the volume is full. You will need a free space on disk to perfo= rm >>>> such operations. Do you know why? >>> >>> Because some extra space needs to be on the volume in order to do the= >>> atomic commit. Specifically, there must be enough extra space to keep= >>> both old and new copies of any changed metadata, plus enough space fo= r >>> new data or metadata. You are almost right: we can't support rm, rmdi= r >>> or truncate _with atomic commit_ unless some space is available on th= e >>> volume. So we keep a small reserve to handle those operations, which >>> only those operations can access. We define the volume as "full" when= >>> only the reserve remains. The reserve is not included in "available" >>> blocks reported to statfs, so the volume appears to be 100% full when= >>> only the reserve remains. >>> >>> For Tux3, that reserve is variable - about 1% of free space, declinin= g >>> to a minimum of 10 blocks as free space runs out. Eventually, we will= >>> reduce the minimum a bit as we develop finer control over how free >>> space is used in very low space conditions, but 10 blocks is not bad >>> at all. With no journal and only 10 blocks of unusable space, we do >>> pretty well with tiny volumes. >> >> Yeah. Filesystem that could not do rm on full filesystem would be >> braindead. >> >> Now, what about >> >> 1) writing to already-allocated space in existing files? > > I mentioned earlier, it seems to work pretty well in Tux3. But do user > applications really expect it to work? I do not know of any, perhaps > you do. I don't know of any applications that do, although I do know of quite a=20 few users who would expect it to work (myself included). This kind of=20 thing could (depending on how the system in question is configured)=20 potentially be critical for recovering from such a situation. --------------ms070607090509050706070201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGuDCC BrQwggScoAMCAQICAxBuVTANBgkqhkiG9w0BAQ0FADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xNTAz MjUxOTM0MzhaFw0xNTA5MjExOTM0MzhaMGMxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEj MCEGCSqGSIb3DQEJARYUYWhmZXJyb2luN0BnbWFpbC5jb20xIjAgBgkqhkiG9w0BCQEWE2Fo ZW1tZWxnQG9oaW9ndC5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCdD/zW 2rRAFCLnDfXpWxU1+ODqRVUgzHvrRO7ADUxRo1CBDc3JSX5TIW2OGmQ3DAKGOACp8Z0sgxMc B05tzAZ/M7m4jajVrwwdVCdrwVGxTdAai7Kwg4ZCVfyMVhcwo8R2eW3QahBx34G0RKumK9sZ ZQSQ+zULAzpY6uz7T1sAk/erMoivRXF6u8WvOsLkOD1F/Xyv1ZccSUG5YeDgZgc0nZUBvyIp zXSHjgWerFkrxEM3y2z/Ff3eL1sgGYecV/I1F+I5S01V7Kclt/qRW10c/4JEGRcI1FmrJBPu BtMYPbg/3Y9LZROYN+mVIFxZxOfrmjfFZ96xt/TaMXo8vcEKtWcNEjhGBjEbfMUEm4aq8ygQ 4MuEcpJc8DJCHBkg2KBk13DkbU2qNepTD6Uip1C+g+KMr0nd6KOJqSH27ZuNY4xqV4hIxFHp ex0zY7mq6fV2o6sKBGQzRdI20FDYmNjsLJwjH6qJ8laxFphZnPRpBThmu0AjuBWE72GnI1oA aO+bs92MQGJernt7hByCnDO82W/ykbVz+Ge3Sax8NY0m2Xdvp6WFDY/PjD9CdaJ9nwQGsUSa N54lrZ2qMTeCI9Vauwf6U69BA42xgk65VvxvTNqji+tZ4aZbarZ7el2/QDHOb/rRwlCFplS/ z4l1f1nOrE6bnDl5RBJyW3zi74P6GwIDAQABo4IBWTCCAVUwDAYDVR0TAQH/BAIwADBWBglg hkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwDgYDVR0PAQH/BAQDAgOoMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4 QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9y ZzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2VydC5vcmcvcmV2b2tlLmNybDA0 BgNVHREELTArgRRhaGZlcnJvaW43QGdtYWlsLmNvbYETYWhlbW1lbGdAb2hpb2d0LmNvbTAN BgkqhkiG9w0BAQ0FAAOCAgEAGvl7xb42JMRH5D/vCIDYvFY3dR2FPd5kmOqpKU/fvQ8ovmJa p5N/FDrsCL+YdslxPY+AAn78PYmL5pFHTdRadT++07DPIMtQyy2qd+XRmz6zP8Il7vGcEDmO WmMLYMq4xV9s/N7t7JJp6ftdIYUcoTVChUgilDaRWMLidtslCdRsBVfUjPb1bF5Ua31diKDP e0M9/e2CU36rbcTtiNCXhptMigzuL3zJXUf2B9jyUV8pnqNEQH36fqJ7YTBLcpq3aYa2XbAH Hgx9GehJBIqwspDmhPCFZ/QmqUXCkt+XfvinQ2NzKR6P3+OdYbwqzVX8BdMeojh7Ig8x/nIx mQ+/ufstL1ZYp0bg13fyK/hPYSIBpayaC76vzWovkIm70DIDRIFLi20p/qTd7rfDYy831Hjm +lDdCECF9bIXEWFk33kA97dgQIMbf5chEmlFg8S0e4iw7LMjvRqMX3eCD8GJ2+oqyZUwzZxy S0Mx+rBld5rrN7LsXwZ671HsGqNeYbYeU25e7t7/Gcc6Bd/kPfA+adEuUGFcvUKH3trDYqNq 6mOkAd8WO/mQadlc3ztS++XDMhmIpfBre9MPAr6usqf+wc+R8Nk9KLK39kEgrqVfzc/fgf8L MaD4rHnusdg4gca6Yi+kNrm99anw7SwaBrBvULYBp7ixNRUhaYiNW4YjTrYxggShMIIEnQIB ATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDEG5VMAkGBSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUyODEyNTUxOFowIwYJKoZIhvcNAQkE MRYEFA4FCutotl9Lw18X5bfMm+2PSrxiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDEG5VMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2ln bmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDEG5V MA0GCSqGSIb3DQEBAQUABIICAI1Ykcl8pYUWAE1WwTd86dAUxZhIUMo4y+XjoPBO23cfeMQi zA0znfLGlsiD6ZlSmr4fIUmveKMJAjsJ2fu/ip0vrRiyHrNz4l9DE2w3fIhJ0Ad324cnXcsM xMfVeCNIKwUnwddmU+5i0CcAAWmk2pOThbr7mgRQ999WqMDChAgR+QaqsUMmlAPzFLDAWUWA rj4YYzvMzWA4F+mEzXmANi6xnLE6a+ccVmluMNxxoHoY9eplZvdpQzdF45a3duYPy8+HSU5C Mkwz9Fu5wldxW4P6Wlfj1GsnX9++f39C8gWUqyTyo09NGfO6ZwZD21drtg0bBTuh02MQJw20 fTWlR/m1F1lJw1WwUIIaZaFkQT7qgcPzxh3xQTwj4+ncxvFVMYBFNHDqB/jXPTWsY7KFa49E EL7FuPvuEo7wVwcDFRqYxzXBanCZ/uaEIYlc3o61TuYrlYcJB1hK/vYLl2oLjr3A0N2v0EaE NrdaGCBX1TiW8nEcKZug/O6q9eb512cDjj+Foqf3WtTtOvHRyKMrEAY+iX0bM3S2S7X1IRq5 P9P4PdQSsWx6DRI7tDpLalknppShIT9GqiE6yubpT7nYp8j/S+CKuXUtAgaBqTk4rtsjCqDV nQvZXYwSGqIwiRqDQ8rEn9maOQLdb1yz/Lk/rHZK5IwsgoMgIMm+AnLpZ2SKAAAAAAAA --------------ms070607090509050706070201--