|
|
 Up |
|
|
  |
Author: roger pepperoger peppe Date: Nov 5, 2007 03:21
On 11/1/07, erik quanstrom quanstro.net> wrote:> i think it makes sense to use the medium changes (not connections, if
> possible) to determine the version. the marvell and aoe driver
> consider a device changed if the serial# or number of sectors
> change.that is something most io clients are interested in.
this kind of thing is fine until you want to run software that
uses the original notion of "version". for instance, i suppose it's
not inconceivable that you could run something like cfs over
such a device.
turning things around, by providing device-specific versioning behavior,
you can end up with clients that won't work well when run over normal
files. if a client expects the version number to change only when the
media changes, then it's quite likely to be fairly surprised if
the version number changes every time it writes some data.
that's why i think that preserving standard semantics is a Good Thing.
it preserves filesystem transparency, one of the nicest
things about plan 9.
|
| Show full article (1.33Kb) |
|
| | 16 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 05:20
> On 11/1/07, erik quanstrom quanstro.net> wrote:>> i think it makes sense to use the medium changes (not connections, if
>> possible) to determine the version. the marvell and aoe driver
>> consider a device changed if the serial# or number of sectors
>> change.that is something most io clients are interested in.
>
> this kind of thing is fine until you want to run software that
> uses the original notion of "version". for instance, i suppose it's
> not inconceivable that you could run something like cfs over
> such a device.
>
> turning things around, by providing device-specific versioning behavior,
> you can end up with clients that won't work well when run over normal
> files. if a client expects the version number to change only when the
> media changes, then it's quite...
|
| Show full article (1.71Kb) |
|
| | 15 Comments |
|
|
Author: roger pepperoger peppe Date: Nov 5, 2007 06:36
On 11/5/07, erik quanstrom quanstro.net> wrote:> i still don't agree that this is anomolous behavior. when the medium
> has changed, the file has changed. it has a new set, and possibly a different
> number of blocks. this is exactly the case where ken's fs or fossil
> assign a new qid.vers.
i agree it's perfectly reasonable to assign a new qid.vers in this case.
but if it's going to do this, i think it should also assign a new qid.vers
when the data file has been written to.
> further, this behavior only holds for /dev/sdXX/data and a few other files, like
> /dev/fd?^(diskc ctl). i don't see how this could break anything.
> could you give a senario that would be broken in this case?
> i can't find any programs that use the qid.version for anything except
> to infer that a file has changed if it qid.vers has changed.
|
| Show full article (2.21Kb) |
| 14 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 07:02
>> further, this behavior only holds for /dev/sdXX/data and a few other files, like
>> /dev/fd?^(diskc ctl). i don't see how this could break anything.
>> could you give a senario that would be broken in this case?
>> i can't find any programs that use the qid.version for anything except
>> to infer that a file has changed if it qid.vers has changed.
>
> i gave one scenario. to expand on it: say dossrv expected this behaviour.
> it would then do an occasional stat; if the qid.vers had changed, it
> would assume that the floppy had been swapped and abort with an error.
> this would mean that i could no longer use dossrv on a conventional
> file, because every time dossrv wrote to the file, it would then
> abort, thinking that the floppy had been swapped because the version
> number had changed...
|
| Show full article (1.25Kb) |
| 12 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 07:30
> um, i don't think i said that it was new behaviour. i did say that i thought it
> was an abuse of the semantics, and i still think so. to me the devfloppy
> code you point to looks like it was just using the Chan as a
> convenient place to store
i think you should complain to presoto or rob. it would be helpful to
do so in 1990. you may need a time machine.
while you're at it, tell ken to spell "creat" with an "e".
and you need to complain about the abuse of wstat() to imply device
i/o flushing.
☺ (just to remove any doubt)
seriously, the fewer rigid rules we make for 9p,
the more adaptable it will be.
the history migration process i built for kenfs
(/n/sources/contrib/quanstro/history.ms)
insures that for any two files on the original fs,
a.file1.qid.vers == a.file2.qid.vers =>
b.file1.qid.vers == b.file2.qid.vers.
|
| Show full article (1.71Kb) |
| no comments |
|
|
Author: roger pepperoger peppe Date: Nov 5, 2007 08:11
On 11/5/07, erik quanstrom quanstro.net> wrote:> i think something's lost in the translation here.
>
> the client is not responsible for checking the qid.version. the
> server (e.g. devsd, devaoe or devfloppy) does the qid checking
> itself.
i'm sorry? the server is the one *generating* the qid, surely?
for instance, in the case of cdfs, the version number comes from the
scsi(2) library function, and doesn't have any necessary correspondence with
qid.vers as found in the data file served by cdfs. so strictly speaking,
the server isn't doing any qid checking at all - it's just looking at
its own data structures.
> using a seperate file to detect media change introduces a
> race. with network-attached media this might be a problem.
there's a race anyway if you're doing the stat in a separate process.
if you're not, then it's the same either way, no?
> the fact is, you can't deal with a physical disk like /dev/sdE0/data
> in the same way you can deal with a regular fileserver.
|
| Show full article (1.78Kb) |
| 11 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 08:41
> i'm sorry? the server is the one *generating* the qid, surely?
> for instance, in the case of cdfs, the version number comes from the
> scsi(2) library function, and doesn't have any necessary correspondence with
> qid.vers as found in the data file served by cdfs. so strictly speaking,
> the server isn't doing any qid checking at all - it's just looking at
> its own data structures.
/n/sources/plan9/sys/src/9/port/devsd.c:177
>> using a seperate file to detect media change introduces a
>> race. with network-attached media this might be a problem.
>
> there's a race anyway if you're doing the stat in a separate process.
> if you're not, then it's the same either way, no?
there is no race. the client does a pread/pwrite blithly. devsd returns
-1, Echange if the medium has changed since the fd was opened.
|
| Show full article (2.45Kb) |
| 9 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 08:43
>> try doing ls -lt /mail/fs/mbox.
>
> i wish this worked!
i do, too. (i made it work in my version.) but that's really beside the point.
fileservers can't be forced to maintain all of the stat fields.
they are free to lie as the wish.
- erik
|
| |
| no comments |
|
|
Author: roger pepperoger peppe Date: Nov 5, 2007 09:07
On 11/5/07, erik quanstrom quanstro.net> wrote:>> i'm sorry? the server is the one *generating* the qid, surely?
>> for instance, in the case of cdfs, the version number comes from the
>> scsi(2) library function, and doesn't have any necessary correspondence with
>> qid.vers as found in the data file served by cdfs. so strictly speaking,
>> the server isn't doing any qid checking at all - it's just looking at
>> its own data structures.
>
> /n/sources/plan9/sys/src/9/port/devsd.c:177
???
i'm probably being stupid here, but all i see there is devsd dealing
with its own data structures, with no external qids involved at all.
an SDunit doesn't correspond with any file that devsd uses, as far as i can see.
> there is no race. the client does a pread/pwrite blithly. devsd returns
> -1, Echange if the medium has changed since the fd was opened.
that's absolutely fine. if that's all that's going on, why bother reflecting
the medium change in qid.vers of the data file? just leave it at 0 and be done
with it.
> it's not expected that the client look at the qid.vers.
|
| Show full article (2.21Kb) |
| 4 Comments |
|
|
|
|
|
Author: erik quanstromerik quanstrom Date: Nov 5, 2007 09:56
>> /n/sources/plan9/sys/src/9/port/devsd.c:177
>
> ???
> i'm probably being stupid here, but all i see there is devsd dealing
> with its own data structures, with no external qids involved at all.
> an SDunit doesn't correspond with any file that devsd uses, as far as i can see.
>
>> there is no race. the client does a pread/pwrite blithly. devsd returns
>> -1, Echange if the medium has changed since the fd was opened.
>
> that's absolutely fine. if that's all that's going on, why bother reflecting
> the medium change in qid.vers of the data file? just leave it at 0 and be done
> with it.
the qid.vers does get exported. i don't think there's a copy of the version stashed
in the kernel that is not visable from the outside.
|
| Show full article (2.43Kb) |
| 3 Comments |
|
|
|
|
