Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932451AbbELLqA (ORCPT ); Tue, 12 May 2015 07:46:00 -0400 Received: from mail-ig0-f177.google.com ([209.85.213.177]:38881 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751873AbbELLpy (ORCPT ); Tue, 12 May 2015 07:45:54 -0400 Message-ID: <5551E7EB.8040301@gmail.com> Date: Tue, 12 May 2015 07:45:47 -0400 From: Austin S Hemmelgarn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kevin Easton , "Theodore Ts'o" CC: Sage Weil , Trond Myklebust , Dave Chinner , Zach Brown , Alexander Viro , Linux FS-devel Mailing List , Linux Kernel Mailing List , Linux API Mailing List Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag References: <20150507002617.GJ4327@dastard> <20150507172053.GA659@lenny.home.zabbo.net> <20150508221325.GM4327@dastard> <20150511144719.GA14088@thunk.org> <20150511231021.GC14088@thunk.org> <20150512050821.GA9404@chicago.guarana.org> In-Reply-To: <20150512050821.GA9404@chicago.guarana.org> x-hashcash: 1:21:150512:kevin@guarana.org::86d4567e7fd13bafffea0fc4b29acdb:5b975da5eacfc358 x-hashcash: 1:21:150512:tytso@mit.edu::8189e2df02c46a5aba0d43926045571:18167b66aca2ec91 x-hashcash: 1:21:150512:sage@newdream.net::2c1c767cd5e862d56fb94e0d00a848:b9c129fa8f0de470 x-hashcash: 1:21:150512:trond.myklebust@primarydata.com::d75c3b1622e46a53786ef5b7f5123ca:e701ca10527a7e29 x-hashcash: 1:21:150512:david@fromorbit.com::4ca9adc41ba210f9cf6c8ba5e65ca97:62d6c5b7132e5a9c x-hashcash: 1:21:150512:zab@redhat.com::529c60953cb0811cc4daa0420e8a45ea:6f2dd7cf584ffc4e x-hashcash: 1:21:150512:viro@zeniv.linux.org.uk::d5fd4771ecf6121424f8eca998bfd96b:e9d5f9d92fbcb8bd x-hashcash: 1:21:150512:linux-fsdevel@vger.kernel.org::d86e8f531abc2b22f5bdcd451ff05e2:951d910818371b3d x-hashcash: 1:21:150512:linux-kernel@vger.kernel.org::a573158473ccc39b39b3da8d0579c074:524312ac758b144d x-hashcash: 1:21:150512:linux-api@vger.kernel.org::38d5481b4e1609e71e936dffc90eb92c:586de5ffa30d78b9 x-stampprotocols: hashcash:1:17;mbound:0:10:3000:5000 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030103080204000003000004" X-Antivirus: avast! (VPS 150511-1, 2015-05-11), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6706 Lines: 118 This is a cryptographically signed message in MIME format. --------------ms030103080204000003000004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-05-12 01:08, Kevin Easton wrote: > On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote: >> On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote: >>>> Let me re-ask the question that I asked last week (and was apparentl= y >>>> ignored). Why not trying to use the lazytime feature instead of >>>> pointing a head straight at the application's --- and system >>>> administrators' --- heads? >>> >>> Sorry Ted, I thought I responded already. >>> >>> The goal is to avoid inode writeout entirely when we can, and >>> as I understand it lazytime will still force writeout before the inod= e >>> is dropped from the cache. In systems like Ceph in particular, the >>> IOs can be spread across lots of files, so simply deferring writeout >>> doesn't always help. >> >> Sure, but it would reduce the writeout by orders of magnitude. I can >> understand if you want to reduce it further, but it might be good >> enough for your purposes. >> >> I considered doing the equivalent of O_NOMTIME for our purposes at >> $WORK, and our use case is actually not that different from Ceph's >> (i.e., using a local disk file system to support a cluster file >> system), and lazytime was (a) something I figured was something I >> could upstream in good conscience, and (b) was more than good enough >> for us. > > A safer alternative might be a chattr file attribute that if set, the > mtime is not updated on writes, and stat() on the file always shows the= > mtime as "right now". At least that way, the file won't accidentally > get left out of backups that rely on the mtime. > > (If the file attribute is unset, you immediately update the mtime then > too, and from then on the file is back to normal). > I like this even better than the flag suggestion, it provides better=20 control, means that you don't need to update applications to get the=20 benefits, and prevents backup software from breaking (although backups=20 would be bigger). --------------ms030103080204000003000004 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 BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDUxMjExNDU0N1owIwYJKoZIhvcNAQkE MRYEFFWhHFxtgXSgmFDThMJFT+9Ox0OsMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGBgzCBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDEG5VMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2ln bmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDEG5V MA0GCSqGSIb3DQEBAQUABIICAGQ+zc7Y5fcUFV86ORdwK4u0C/G+qV685y3JTOSYgPqvAGuY iJd5nn56akh6VQMtr34eB7rqjxrfKA2YTNmMCjqK8yRQS5Hk7m0CMUbsZvrJZT/8Kp5m95Sv rRmLIMkyhdSyxgiUfll7ZoZ+7gA3n7wROYWZrZk39MjO/AyL1EtGGdXplBsOwbrQZEWTA0x8 cBlQwGaDUwdJRxPteBhJ8Tx1G1/wHYhcHpPjmFJDeZJRTC3mP5uYnmyqvQao2YQYNl+dtDAk 663AOj5WfOrqUqCBTycWpxPpFWHHWcf+IyMJ4mozI2qEDJqrcmIea1ZM216/Cx/RNNr02Fzx d0tZGIaMnHr2f8KI20Hh+EzmCzuPoqSEeVdpZOMta/Rl8PqrsxP3dCYaYY3K2rTGp3IDOVmb DWG/8r2oDOaKuRd/5J2Ju0gF9xjpGeYtd7zPgshquhADYGRwHAzLpU8pqC6tc1NEVLqozAdd psEbpOstxOg022iFQR/nKnmVg5zLqPihDh1ruCN5tm+xaz6vM56q/nqJ7gyBp6yNM9hqErfM uEs3FdwtUEFbhrjV2aI8MSfM3Jfhf2ka6UDMPkRQHEBcejH0a7Qzc1MsB9Q7oqynCd03erBd wCjuChSCFKHzcIlt7B/r5x8llO4XZtqm6d4leOlsyW5Zpc2hyV9WtTjwWj7XAAAAAAAA --------------ms030103080204000003000004-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/