Re: [9fans] RAID box with plan9 filesystem

[Charles Forsyth]

Many file servers using disk drives are unreliable if you shut them down
without saving data in memory first.
Both /sys/src/fs and disk/kfs force certain metadata updates to disk first
to try to ensure that the fs structure,
if not the content, remains consistent. In fact, disk/kfs does more than
the old file server (it forces indirect block
updates out as well). Disk/kfs only seemed less reliable than the old file
system because it is more likely
to be shut down without syncing. Also, the old file server could be
recovered from a consistent root
if the worm dump was used. If you sync, you shouldn't have too much trouble.
Of course, forcing write-through makes the file system slower than some
others
for updates. At the cost of some code complexity, fossil attempts to do
better, using a soft update
scheme to ensure or attempt to ensure that everything on disk is
consistent. It's mentioned
briefly in the paper.

On 25 December 2011 16:30, Aram Hăvărneanu ara...@mgk.ro wrote:

  I
 have heard very good things about the reliability of both.  You say
 kfs is not very reliable, oh well.

[9fans] fake tty or other trick?

[Jens Staal]

Hi all

I have been playing with trying to get the current MirOS ksh (mksh) to
compile and run under APE. It now compiles but as it is executed it
complains about no /dev/tty and crashes as soon as I try to write a
command to it.

Since the pdksh was ported as the generic APE 'sh' I guess the
tty-issue has been solved once before. Any pointers?

current source and temporary (ugly) solutions can be seen here:
http://code.google.com/p/ports2plan9/source/browse/#hg%2Fmksh

[9fans] p9p vac/vacfs compatibility: uid/gid, ctime, 9P2000.L, 9pserve

[smiley]

Hello,

I'm trying to use vac/vacfs on p9p, using the Linux v9fs driver (-t 9p)
with unix domain sockets as transport (-o trans=unix).  And I'm
confused.  :(

When I mount the file system, all the files are owned by uid = gid = (-2
mod 2^32), unless I tell the Linux kernel to mount the fs as a specific
user/group.  In the latter case, all files present with the specified
user/group (as expected).  I can't find any way to get at the actual
uid/gids owning the files/directories vac'd.  I have tried explicitly
specifying -o version=9p2000.u, but it exhibits the same symptoms: all
files and directories appear to be owned by uid = gid = (-2 mod 2^32).
All uids/gids in the vac'd tree existed in /etc/{passwd,group} at the
time of vac'ing, as well as at mount time.

So, I took a little looksie in /usr/lib/plan9/src/cmd/vac/...


/usr/lib/plan9/src/cmd/vac/vac.c:48
#ifdef PLAN9PORT
/*
 * We're between a rock and a hard place here.
 * The pw library (getpwnam, etc.) reads the 
 * password and group files into an on-stack buffer,
 * so if you have some huge groups, you overflow
 * the stack.  Because of this, the thread library turns
 * it off by default, so that dirstat returns 14571 instead of rsc.
 * But for vac we want names.  So cautiously turn the pwlibrary
 * back on (see threadmain) and make the main thread stack huge.
 */
extern int _p9usepwlibrary;
int mainstacksize = 4*1024*1024;

#endif


/usr/lib/plan9/src/cmd/vac/vac.c:399
vd-uid = dir-uid;
vd-gid = dir-gid;
vd-mid = dir-muid;


So, the source *appears* to stow uid/gid to venti as character strings.

BTW,


/usr/lib/plan9/src/cmd/vac/vac.c:406
vd-ctime = dir-mtime; /* ctime: not available on plan 9 */



Does this mean that vac doesn't store ctimes on p9p?  Shouldn't this be
wrapped in something like:


#ifdef PLAN9PORT
vd-ctime = dir-ctime; /* ctime: available on p9p */
#else
vd-ctime = dir-mtime; /* ctime: not available on plan 9 */
#endif



Then, we have:

/usr/lib/plan9/src/cmd/vac/vacfs.c:696
dir.atime = vd-atime;
dir.mtime = vd-mtime;
dir.length = vd-size;

dir.name = vd-elem;
dir.uid = vd-uid;
dir.gid = vd-gid;
dir.muid = vd-mid;
#ifdef PLAN9PORT
dir.ext = ext;
dir.uidnum = atoi(vd-uid);
dir.gidnum = atoi(vd-gid);
#endif



Those dir.uidnum and dir.gidnum don't appear to be referenced anywhere
else in the code.  But it makes me wonder... are the character string
uid/gids vac'd the textual names from /etc/{passwd,group}, or just ASCII
versions of the numeric ids, a la format %d?

And just what is 9P2000.L, anyway?  I can't seem to find any
documentation on it.

Last, but not least, can anyone tell me why 9pserve is taking up so much
CPU time?  From the docs, it looks like 9pserve should just be muxing 9p
connections and passes messages around.  I had expected that disk
bandwith would be the bottleneck in my setup.  But, as it turns out, the
bottleneck is actually this little fellow, 9pserve.  I have no idea why
it's taking so much CPU to multiplex 9p, especially since there's only
one connection being multiplexed!  Is there any way to bypass 9pserve
(since I only need one connection for now), i.e., doing 9p on sockets or
shared file descriptors?

Thanks!
-- 
+---+
|Smiley   smi...@icebubble.orgPGP key ID:BC549F8B |
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---+

Re: [9fans] p9p vac/vacfs compatibility: uid/gid, ctime, 9P2000.L, 9pserve

[David du Colombier]

 When I mount the file system, all the files are owned by uid = gid =
 (-2 mod 2^32), unless I tell the Linux kernel to mount the fs as a
 specific user/group.  In the latter case, all files present with the
 specified user/group (as expected).  I can't find any way to get at
 the actual uid/gids owning the files/directories vac'd.  I have tried
 explicitly specifying -o version=9p2000.u, but it exhibits the same
 symptoms: all files and directories appear to be owned by uid = gid =
 (-2 mod 2^32). All uids/gids in the vac'd tree existed
 in /etc/{passwd,group} at the time of vac'ing, as well as at mount
 time.

The problem you are encountering is that v9fs doesn't translate
uid/gid strings back to their numeric equivalent in /etc/passwd.
Since Unix doesn't know how to handle these strings, it falls
back to -1.

Forget about 9p2000.u, it's deprecated.

 So, the source *appears* to stow uid/gid to venti as character
 strings.

This is the case. You can show the actual uid/gid from the
Plan 9 vacfs and even on p9p, using vacfs -d.

 Does this mean that vac doesn't store ctimes on p9p?
 Shouldn't this be wrapped in something like:

Yes, vac doesn't store ctime. Maybe we could store it in vac,
as you suggest, but 9P doesn't handle it anyway.

 Those dir.uidnum and dir.gidnum don't appear to be referenced anywhere
 else in the code.

I never paid much attention to it. It looks unused.

 But it makes me wonder... are the character string
 uid/gids vac'd the textual names from /etc/{passwd,group}, or just
 ASCII versions of the numeric ids, a la format %d?

They are the textual names.

The problem you are describing is not related to vac nor vacfs.
They both handle uid/gid properly, and, as you saw, p9p vac can
even translate numeric uid/gid to their string representation.

-- 
David du Colombier