[9fans] ide fs patch for the current plan9 version

[ne...@gsyc.escet.urjc.es]

Hi,

this is just edorman's patch for the fs kernel to let it work
with ide disks. Unlike the original patch as posted in 9fans,
this one can be `applied' to the current fs
kernel source. There is almost no change actually.

I don't know if the patch might break the fs code for regular scsi disks,
since it is `removing' some code which seems to be working on a scsi-based
fs. I couldn't try because I don't have scsi disks around.

In any case, I'm using the current fs code w/ this patch applied and it
seems to work ok.
My configuration string (if I remember well) is ch0fh2. The
block size is 16K, but you may change the define for RBUFSIZE in
plan9pc/dat.h.

I'll try to keep the patch up-to-date wrt the distributed fs code
until the day when the new integrated fs code be done and released.

To apply the patch, I suggest you create two directories
./idefs/port and ./idefs/plan9pc, then run rc idefs.rc on ./idefs and
bind -bc ./idefs/port /sys/src/fs/port
bind -bc ./idefs/plan9pc /sys/src/fs/plan9pc

after that you can mk in /sys/src/fs/plan9pc.

hope this helps

[ge...@collyer.net]

> To apply the patch, I suggest you create two directories
> ./idefs/port and ./idefs/plan9pc, then run rc idefs.rc on ./idefs and
> bind -bc ./idefs/port /sys/src/fs/port
> bind -bc ./idefs/plan9pc /sys/src/fs/plan9pc
>
> after that you can mk in /sys/src/fs/plan9pc.

You probably ought to "mk clean" before you "mk" in
/sys/src/fs/plan9pc. We tried this sort of overlaid source tree and
found a couple of hazards: existing object (.8) files in the
underlying tree (/sys/src/fs in this case) can cause trouble if they
are unwritable (e.g., due to lack of permission) or if they are newer
than source files in the overlaying tree (./idefs in this case).

Russ and I didn't quite finish a program called stitch to perform this
sort of overlay dynamically (it worked under light load). Stitch
changed the semantics of creation slightly so that new files in the
served tree were always created in the uppermost layer, though that
could be easily adjusted. I also made a small tweak to mk to
understand enough about overlays that it would ignore targets (e.g.,
newer object files) in lower layers for the purpose of computing work
to be done.

[Francisco J Ballesteros]

ge...@collyer.net wrote:

> You probably ought to "mk clean" before you "mk" in
> /sys/src/fs/plan9pc. We tried this sort of overlaid source tree and
> found a couple of hazards: existing object (.8) files in the
> underlying tree (/sys/src/fs in this case) can cause trouble if they
> are unwritable (e.g., due to lack of permission) or if they are newer
> than source files in the overlaying tree (./idefs in this case).
>
> Russ and I didn't quite finish a program called stitch to perform this
> sort of overlay dynamically (it worked under light load). Stitch

Isn't it more simple just to keep the source directory always clean and
always overlay your one before mk'ing?
Or am I missing something?

[ge...@collyer.net]

Yes, it is simpler to just keep the source tree clean, if you have
that option. My ex-department tried the experiment of overlaying the
contents of our file server, which we kept pretty lean, on top of the
main Plan 9 file server. It kept us current yet allowed us to
implement different administrative policies and in general substitute
our own files for those on the main file server. We didn't have
permission to clean the main source tree.

[Eric Dorman]

ne...@gsyc.escet.urjc.es wrote:
> Hi,

> I'll try to keep the patch up-to-date wrt the distributed fs code
> until the day when the new integrated fs code be done and released.

good deal. doesn't look like i'm going to get back
to it... Real Life(TM) intrudes...

--eld