From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <485ffa6d8f530b309097560ab32bb43d@lilly.quanstro.net> References: <36c9016b7918c302d777f1a605fc107f@brasstown.quanstro.net> <2CBEED8D-800D-40C8-8182-162695D9FF30@9srv.net> <45fe7ac7a1dab989624aa4ed2b376ff9@brasstown.quanstro.net> <485ffa6d8f530b309097560ab32bb43d@lilly.quanstro.net> Date: Wed, 4 Feb 2015 22:24:59 +0100 Message-ID: From: Giacomo Tesio To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c36724d91cb7050e49d111 Subject: Re: [9fans] wstat and atomic directory change Topicbox-Message-UUID: 401cb5e8-ead9-11e9-9d60-3106f5b1d025 --001a11c36724d91cb7050e49d111 Content-Type: text/plain; charset=UTF-8 Useless? No I did not mean this. (and sorry, I wasn't in any way sarcastic, I'm just trying to understand 9p's design a bit deeper) I mean that to realize a truly uniform interface, directories should be writable with Twrite, so that we would not need messages like Tcreate and Tremove (and possibly Twstat) and Tstat would just be an efficient shortcut (like it actually already is, since we can obtain the same info reading the parent directory). We could add a file by appending a stat entry to the parent directory and we could remove it by removing such entry. We could modify permissions, names and so on overwriting the entry. The problem would be: how to do such basic operations atomically and concurrently? That's why (I suppose) we have Tcreate, Tremove and Twstat. For praticality. But why we don't have Tmove for example? Probably the answer is in the distributed nature of Plan 9: as you said, namespaces would be at odds with such a message, complicating the library functions. However having to read and write a 10 GB file one msize after the other just to change its directory looks a bit costly, if both the origin and the destinations are in the same phisical disk. Moreover (if I've understood properly the protocol) to move a 10 GB file between two directories on a disk, you should have 10 GB free on that disk! All this reflections arise from the search for an orthodox way to change the tree structure of a synthetic filesystem. Moving large real files is not my actual issue here. I'm wondering for a synthetic filesystem in which, when you move a folder in a special directory, something magic happens. As far as I can see, it is not possible with a 9p2000 fileservice, is it? Giacomo 2015-02-04 20:23 GMT+01:00 erik quanstrom : > > you can consider doing it out of band; e.g. a new fossil console command. > > On Wed, Feb 4, 2015 at 6:30 AM Giacomo Tesio wrote: > > > > > And unfortunately I cannot figure out any alternative, either. :-( > > > > > > An interesting point is: why directory entries can be read but cannot > be > > > written? I mean we use Tcreate to create a new file in a dir, while to > be > > > uniform with files, we should use a Twrite, appending a corresponding > stat > > > structure at the end of a directory entry. > > > > > > However this solution probably has not been adopted to enable safe > > > concurrency in the file creation and removal. > > > > > > However this asymmetry shows that directories cannot be (pratically) > > > handled in the same way of files. > > right. directories are not the same as files. you're right that reading a > directory is useless. > > - erik > > --001a11c36724d91cb7050e49d111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Useless? No I did not mean this.
(and sorry, I wasn'= ;t in any way sarcastic, I'm just trying to understand 9p's design = a bit deeper)
I mean that to realize a truly uniform interface, director= ies should be writable with Twrite, so that we would not need messages like= Tcreate and Tremove (and possibly Twstat) and Tstat would just be an effic= ient shortcut (like it actually already is, since we can obtain the same in= fo reading the parent directory).

We could add a file by appending a= stat entry to the parent directory and we could remove it by removing such= entry. We could modify permissions, names and so on overwriting the entry.=
The problem would be: how to do such basic operations atomically and co= ncurrently?

That's why (I suppose) we have Tcreate, Tremove and = Twstat. For praticality.
But why we don't have Tmove for example?
Probably the answer is in the distributed nature of Plan 9: as you sai= d, namespaces would be at odds with such a message, complicating the librar= y functions.
However having to read and write a 10 GB file one msize aft= er the other just to change its directory looks a bit costly, if both the o= rigin and the destinations are in the same phisical disk.
Moreover (if I= 've understood properly the protocol) to move a 10 GB file between two = directories on a disk, you should have 10 GB free on that disk!

All = this reflections arise from the search for an orthodox way to change the tr= ee structure of a synthetic filesystem.
Moving large real files is not m= y actual issue here. I'm wondering for a synthetic filesystem in which,= when you move a folder in a special directory, something magic happens.As far as I can see, it is not possible with a 9p2000 fileservice, is it?<= br>

Giacomo


2015-02-04 20:23 GMT+01:00 erik quanstrom <quanstro@q= uanstro.net>:
> you can consider doing it out of band; e.g. a new fossil console= command.
> On Wed, Feb 4, 2015 at 6:30 AM Giacomo Tesio <giacomo@tesio.it> wrote:
>
> > And unfortunately I cannot figure out any alternative, either. :-= (
> >
> > An interesting point is: why directory entries can be read but ca= nnot be
> > written? I mean we use Tcreate to create a new file in a dir, whi= le to be
> > uniform with files, we should use a Twrite, appending a correspon= ding stat
> > structure at the end of a directory entry.
> >
> > However this solution probably has not been adopted to enable saf= e
> > concurrency in the file creation and removal.
> >
> > However this asymmetry shows that directories cannot be (pratical= ly)
> > handled in the same way of files.

right.=C2=A0 directories are not the same as files.=C2=A0 you're= right that reading a
directory is useless.

- erik


--001a11c36724d91cb7050e49d111--