9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] lnfs(1)
@ 2002-07-11  4:19 okamoto
  0 siblings, 0 replies; 5+ messages in thread
From: okamoto @ 2002-07-11  4:19 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

Yeah!
I was fool enough to accept new concept!
Yes, I should have done unmount /usr/sys, because I mounted
long filename server on it!

Thanks ア

Kenji


[-- Attachment #2: Type: message/rfc822, Size: 2022 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] lnfs(1)
Date: Thu, 11 Jul 2002 00:03:51 -0400
Message-ID: <20020711040533.EF77219A85@mail.cse.psu.edu>

// When I killed lnfs process after using [lnfs], I cannot
// ccess the whole directory...

i suspect you need to do something like "unmount /usr/sys"
before killing the process (and the unmount may cause the
process to exit, as 'rm /srv/9660' causes 9660srv to exit).
otherwise you've got an entry in your mount table, but no
process to actually service it.
ア

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] lnfs(1)
@ 2002-07-11  4:03 anothy
  0 siblings, 0 replies; 5+ messages in thread
From: anothy @ 2002-07-11  4:03 UTC (permalink / raw)
  To: 9fans

// When I killed lnfs process after using [lnfs], I cannot
// ccess the whole directory...

i suspect you need to do something like "unmount /usr/sys"
before killing the process (and the unmount may cause the
process to exit, as 'rm /srv/9660' causes 9660srv to exit).
otherwise you've got an entry in your mount table, but no
process to actually service it.
ア


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] lnfs(1)
@ 2002-07-11  3:39 okamoto
  0 siblings, 0 replies; 5+ messages in thread
From: okamoto @ 2002-07-11  3:39 UTC (permalink / raw)
  To: 9fans

Thanks Dave.
I'm just a newbie to release 4 Plan 9, and have no time to read codes yet,
and now am just reading the papers.  Facttum is quiet interesting
approach, then, I decided to apdate our release 3 system to the new.
Yes, I haven't done it before, because I've been satisfied in release 3.
Factotum fashionated me to pay effort for it.  ^_^

Ok, I got we can leave .longnames alone till we can see next real file server.

What about the last lines I wrote?   When I killed lnfs process after using it,
I cannot access the whole directory which indicates the lnfs mountpoint.

Kenji



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] lnfs(1)
@ 2002-07-11  3:22 presotto
  0 siblings, 0 replies; 5+ messages in thread
From: presotto @ 2002-07-11  3:22 UTC (permalink / raw)
  To: 9fans


On Wed Jul 10 22:54:41 EDT 2002, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> I'm now using kfs system, and have a question on lnfs(1).
> 
> term% cd /usr/sys
> term% mkdir 大阪府大地学教室岡本健二
> can't create 大阪府大地学教室岡本健二:  name too long
> 
> Yes, I know it, then
> term% lnfs /usr/sys
> term% mkdir 大阪府大地学教室岡本健二
> Ok!, good, I see 大阪府大地学教室岡本健二 directory.
> term% cat .longnames
> 大阪府大地学教室岡本健二
> 
> Then,
> term% rm 大阪府大地学教室岡本健二
> Ok, dir 大阪府大地学教室岡本健二 has been removed.
>  However,
> term% cat .longnames
> 大阪府大地学教室岡本健二
> still shows the removed directory name.
> 
> term% disk/ksync
> term% cat .longnames
> 大阪府大地学教室岡本健二
> 
> then, I killed the lnfs process.
> Then, I cannot access /usr/sys directory anymore...
> 
> What I did wrong?
> 
> Kenji
> 

Nothing ever gets removed from .longnames.  However, removing
the file does get rid of it and you won't see it in a subsequent
ls.  If you want to change lnfs to garbage collect the .longnames
file, go right ahead.  I didn't think it was worth is since its
just a stopgap till seanq and jmk get the next file server working
but if you're going to be using it heavily...

In case you haven't looked at the code, .longnames is just a set of
possible long names.  When you try to open a long name under lnfs's
mount point, .longnames doesn't even get used.  lnfs just tries
to open the real file whose name is the first 26 characters of
the base64 encoding of the sha1 hash of the long name.  .longnames
just gets used to translate the names from sha1's to strings
when you read a directory.  If the possibility of an accidental
hit in sha1 is ~ 2^80, then this will be ~ 2^32 since we are only
encoding about 65 of the 160 bits.  This assumes a linearity that
I'm not sure exists in sha1.  Not wonderful odds but fine for a
stopgap.

Also, in case you haven't noticed, it allows spaces in the names:

% lnfs drafts
% > drafts/'spaces in file names  suck'
% echo drafts/spa*
drafts/spaces in file names  suck
% ls drafts/spa*
'drafts/spaces in file names  suck'

Hence, all mail threads fill the same well needed void.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9fans] lnfs(1)
@ 2002-07-11  2:52 okamoto
  0 siblings, 0 replies; 5+ messages in thread
From: okamoto @ 2002-07-11  2:52 UTC (permalink / raw)
  To: 9fans

I'm now using kfs system, and have a question on lnfs(1).

term% cd /usr/sys
term% mkdir 大阪府大地学教室岡本健二
can't create 大阪府大地学教室岡本健二:  name too long

Yes, I know it, then
term% lnfs /usr/sys
term% mkdir 大阪府大地学教室岡本健二
Ok!, good, I see 大阪府大地学教室岡本健二 directory.
term% cat .longnames
大阪府大地学教室岡本健二

Then,
term% rm 大阪府大地学教室岡本健二
Ok, dir 大阪府大地学教室岡本健二 has been removed.
 However,
term% cat .longnames
大阪府大地学教室岡本健二
still shows the removed directory name.

term% disk/ksync
term% cat .longnames
大阪府大地学教室岡本健二

then, I killed the lnfs process.
Then, I cannot access /usr/sys directory anymore...

What I did wrong?

Kenji



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-07-11  4:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-11  4:19 [9fans] lnfs(1) okamoto
  -- strict thread matches above, loose matches on Subject: below --
2002-07-11  4:03 anothy
2002-07-11  3:39 okamoto
2002-07-11  3:22 presotto
2002-07-11  2:52 okamoto

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).