From: ron minnich <rminnich@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] Questions/concerns on gefs
Date: Mon, 26 Aug 2024 07:36:25 -0700 [thread overview]
Message-ID: <CAP6exYLhZ01EMENX6xxt+ZBtdeQn=uEWcpb_Zd+9ZeGQui4UjQ@mail.gmail.com> (raw)
In-Reply-To: <be059bcf-e329-43c5-bce8-9e457a9d7814@fjrhome.net>
[-- Attachment #1.1: Type: text/plain, Size: 2856 bytes --]
suppose you are cp'ing a directory from a single place to a place that is
backed by several mount points, i.e. the destination is backed by several
servers. Suppose, further, that the source is coming from multiple servers.
Each 9p server knows only of itself; it may well think it can copy /bin to
/bin, when in fact your /bin is full of bind mounts, and your idea of /bin,
and the servers idea of /bin, are very different.
This is the kind of corner case that is rare, but difficult.
On Mon, Aug 26, 2024 at 1:14 AM Frank D. Engel, Jr. <fde101@fjrhome.net>
wrote:
> One way to handle that would be to extend 9p to include a duplicate
> command of some sort. Then the utility would simply note that the file is
> being copied to the same file server it is already located on and ask that
> file server to duplicate it. If the file server does not support the
> command it reports an error back and cp falls back on its existing behavior.
>
> That prevents the issue of cp needing to be familiar with the individual
> file servers and minimizes the required changes, while still allowing for
> the possibility of taking advantage of the more advanced functionality
> being proposed.
>
>
> On 8/26/24 03:43, Steve Simon wrote:
>
>
> sorry to be negative, but i think this is not a good idea.
>
> copying directories does happen but it rare.
>
> cp is small, neat, and clean. adding special optimisations for some
> backends/filesystems would be a mistake. don’t forget cp is often used with
> filesystems other than the main backend file store, whatever that is.
>
> an example of how badly this can go can be seen in the qnx source where
> every utility knows how to handle every fileserver:
>
> [image: openqnx.png]
>
> openqnx/trunk/utils/c/cp/cp.c at master · vocho/openqnx
> <https://github.com/vocho/openqnx/blob/master/trunk/utils/c/cp/cp.c>
> github.com
> <https://github.com/vocho/openqnx/blob/master/trunk/utils/c/cp/cp.c>
> <https://github.com/vocho/openqnx/blob/master/trunk/utils/c/cp/cp.c>
>
> i would suggest keep it simple.
>
> -Steve
>
>
>
> On 26 Aug 2024, at 5:47 am, James Cook <falsifian@falsifian.org>
> <falsifian@falsifian.org> wrote:
>
>
>
> There's nothing in 9p that allows copy to be smart about COW,
>
> so it isn't.
>
>
> It may be worth noting cp could nonetheless be made (mostly) COW by being
> clever about noticing recently-read data being written back. Hammer2 does
> this. At [0]: "... This means that typical situations such as when copying
> files or whole directory hierarchies will naturally de-duplicate. Simply
> reading filesystem data in makes it available for deduplication later."
>
> I have no idea whether that would be appropriate for gefs.
>
> --
> James
>
> [0] http://apollo.backplane.com/DFlyMisc/hammer2.txt
>
>
[-- Attachment #1.2: Type: text/html, Size: 6845 bytes --]
[-- Attachment #2: openqnx.png --]
[-- Type: image/png, Size: 63506 bytes --]
prev parent reply other threads:[~2024-08-26 14:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 9:04 Timothy Robert Bednarzyk
2024-08-15 9:21 ` Steve Simon
2024-08-15 9:42 ` Stuart Morrow
2024-08-15 14:22 ` ori
2024-08-15 14:47 ` ori
2024-08-26 4:45 ` James Cook
2024-08-26 7:43 ` Steve Simon
2024-08-26 8:10 ` Frank D. Engel, Jr.
2024-08-26 8:26 ` Alex Musolino
2024-08-26 14:36 ` ron minnich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAP6exYLhZ01EMENX6xxt+ZBtdeQn=uEWcpb_Zd+9ZeGQui4UjQ@mail.gmail.com' \
--to=rminnich@gmail.com \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).