From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-it0-f48.google.com ([209.85.214.48]) by ewsd; Tue Feb 13 15:09:50 EST 2018 Received: by mail-it0-f48.google.com with SMTP id 140so4196221iti.0 for <9front@9front.org>; Tue, 13 Feb 2018 12:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sphericalharmony-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:to:subject:mime-version; bh=FEIwga+WbxLsUvFhzDtaG8/9LE+tNKKuRNltltWrPl4=; b=ghMvRPgn4UrXZEKuZ7T2oUxKYW90Xhr3v/KAmbdfpw9DdnfnheDOHmi4rGS7uo43Gk ajR7K4A+EIHudhCquosuLLTUxkePBAwWdoiId/grYAMF1OOLdHH6+NiMjbdYKxapZEu2 bC3unF5pe9K0z97Wy044x1AMm1EUC6JelUj/CT2uTVatH51wXU4iwt2TvYlwP0wAMfXg OmpnaVRSwpckAEKlQATZy6CqYVKPpsH4Hk66clDTv9gbuIh9Fs+7sto3g6/TrpS4DS+4 3pNUcTYhAdX5wK/KnQQiDoo5CU0pIwdem9VG8aPPdBhPQMYOKHTaiGGPzcn7nObaxv+L K9IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:to:subject:mime-version; bh=FEIwga+WbxLsUvFhzDtaG8/9LE+tNKKuRNltltWrPl4=; b=tFkn+OHBGSNnYlKMoij5aYiJi304LhVTAKiScFnHeU7aMV5kcFt3xtI0ip1bwfge+n gZBYG7AGPprqbXUSh9mZypx55Oj1HCEUG1Tw8Roh3KsI1gcUSmlfWxosdMjO9qEH5WkB qfo6jxFEeDLIU8WQh0DuBM7d08401nq7NwG8gnN4eTjcpJPtEfJxtgDDgK2jPZP4gvn6 /e9hEhHL9NOxQyWpiHgJ735MHLS80mB4xfP3gRL22rqY7ud46hDuYEb+qsv83yBb2S6O jiEicseWzWkB/PERDQd+blCDJI9pISk9nvLeZZOnrgKqln1Xuq/BnCM4PXF4LLy6N40Y xLbw== X-Gm-Message-State: APf1xPB9NdXvMHGFvKtRQMky288hEr1obRyOK7xHOGWVbi95xptZjWG6 iN12T0esBcu772eoB1KeNQGqBEtP X-Google-Smtp-Source: AH8x226IG94RUlrHkD5WKvriXDUr2rJWX84O/395G58kcNw6+eNh3rCbtTo5TxhbU5YnIil7+Eu/RA== X-Received: by 10.36.7.209 with SMTP id f200mr277592itf.124.1518552586272; Tue, 13 Feb 2018 12:09:46 -0800 (PST) Return-Path: Received: from x240.Home (h184-61-51-222.burkwi.dedicated.static.tds.net. [184.61.51.222]) by smtp.gmail.com with ESMTPSA id i189sm11393023itf.33.2018.02.13.12.09.45 for <9front@9front.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Feb 2018 12:09:45 -0800 (PST) From: mycroftiv@sphericalharmony.com X-Google-Original-From: glenda@sphericalharmony.com Message-ID: <9BDA4290D351360B58546007996BD00F@sphericalharmony.com> Date: Tue, 13 Feb 2018 20:09:38 +0000 To: 9front@9front.org Subject: ftpfs no-cache patch MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-znfuzhelcenztfdnhboxpvfxfw" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: ISO-certified leveraged database API replication-oriented frontend This is a multi-part message in MIME format. --upas-znfuzhelcenztfdnhboxpvfxfw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Summary: ftpfs caching behavior seems mostly undesirable. This patch eliminates caching by default and allows the previous behavior to be restored with a -h flag. Details: the ftpfs manpage currently states "Ftpfs caches files and directories. A directory will fall from the cache after 5 quiescent minutes or if the local user changes the directory by writing or removing a file." - but I believe this is not accurate. According to my testing, there is no time-based directory cache expiry. The ftpfs.h file does define an ISOLD macro that would fit the manpage, but a grep reveals that the ISOLD macro is never used anywhere in the current code. The cache can be cleared by using the special .flush.ftpfs directory entry. Right now, the 9gridchan public grid is using ftpd/ftpfs to store files with more rapid upload/download than are available from the 9p ramfs service. Clients also transmit messages via a shared plumber to cause other connected users to view images and documents. The current ftpfs behavior clashes badly with this mode of usage - someone uploads a file, and no one else can see it and it cannot be plumbed until/unless clients and the plumber hit the .flush.ftpfs. Given modern networks and machines, the caching seems unnecessary even in usage situations other than the public grid. From looking at the code, the only complication I see might be the the way the caching is used to create synthetic top directories for the VM and VMS operating systems in proto.c. The patch is implemented crudely by finding all the uses of the ISCACHED macro in the code and making them conditional on the -h docache flag. This leaves the calls to uncache() and uncachedir() unchanged but I don't believe this has any negative consequences. The patch has been only lightly tested and seems to do the trick as desired, but I haven't studied the code or tested extensively enough to guarantee that there aren't any other side effects. If people think the current behavior should remain the default, with the flag being used to turn off caching, that seems just as good to me and the patch could remain the same except flipping the polarity of the tests and changing the var name from 'docache' to 'nocache' and changing my edit to the manpage to reflect this. In general ftpfs is a crufty relic of an earlier era, but we are getting some use from it on the public grid, so I thought I'd put this forward. -mycroftiv --upas-znfuzhelcenztfdnhboxpvfxfw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit --- /sys/src/cmd/ip/ftpfs/ftpfs.c Sat Dec 31 17:31:22 2016 +++ ftpfs.c Mon Feb 12 17:21:42 2018 @@ -85,6 +85,7 @@ char *nosuchfile = "file does not exist"; char *keyspec = ""; +int docache = 0; void usage(void) @@ -149,6 +150,9 @@ case 'q': quiet = 1; break; + case 'h': + docache = 1; + break; } ARGEND if(argc != 1) usage(); @@ -401,7 +405,7 @@ /* everything else */ node = extendpath(node, s_copy(elems[i])); - if(ISCACHED(node->parent)){ + if(docache && ISCACHED(node->parent)){ /* the cache of the parent is good, believe it */ if(!ISVALID(node)){ err = nosuchfile; @@ -454,7 +458,7 @@ filedirty(f->node); } else { /* read the remote file or directory */ - if(!ISCACHED(f->node)){ + if(!docache || !ISCACHED(f->node)){ filefree(f->node); if(f->node->d->qid.type & QTDIR){ invalidate(f->node); @@ -464,7 +468,8 @@ if(readfile(f->node) < 0) return errstring; } - CACHED(f->node); + if(docache) + CACHED(f->node); } } @@ -534,10 +539,11 @@ } } else { /* reread file if it's fallen out of the cache */ - if(!ISCACHED(f->node)) + if(!docache || !ISCACHED(f->node)) if(readfile(f->node) < 0) return errstring; - CACHED(f->node); + if(docache) + CACHED(f->node); rv = fileread(f->node, (char*)mbuf, off, cnt); if(rv < 0) return errstring; @@ -614,10 +620,11 @@ Node *p; p = f->node->parent; - if(!ISCACHED(p)){ + if(!docache || !ISCACHED(p)){ invalidate(p); readdir(p); - CACHED(p); + if(docache) + CACHED(p); } if(!ISVALID(f->node)) return nosuchfile; --upas-znfuzhelcenztfdnhboxpvfxfw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit --- /sys/man/4/ftpfs Tue Jan 17 18:13:59 2012 +++ ftpfs.man Tue Feb 13 02:42:57 2018 @@ -4,7 +4,7 @@ .SH SYNOPSIS .B ftpfs [ -.B -/dqnt +.B -/dqnth ] [ .B -m @@ -90,6 +90,10 @@ To see all messages from the server use option .BR -d . .PP +By default ftpfs does no caching of files from the remote server. The +.BR -h +flag enables caching. This flag may be necessary when connecting to VM and VMS systems. +.PP Some systems will hangup an ftp connection that has no activity for a given period. The .BR -K @@ -183,11 +187,7 @@ However, walking to any valid directory on that machine will succeed and cause that directory entry to appear under the mount point. .PP -.I Ftpfs -caches files and directories. A directory will fall from the cache -after 5 quiescent minutes or if the local user changes the -directory by writing or removing a file. -Otherwise, remote +If caching is active, remote changes to the directory that occur after the directory has been cached might not be immediately visible. Attempting to walk to --upas-znfuzhelcenztfdnhboxpvfxfw--