[9fans] mount acme on plan9port

[9fans] mount acme on plan9port

[Lorenzo Bolla]

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

Hi all,
I'm trying to use "9 mount" to mount acme's socket (in `namespace`/acme) to
some directory in /mnt (let's say /mnt/acme). I'm using ArchLInux:
$> uname -a
Linux eee 2.6.32-ARCH #1 SMP PREEMPT Sat Dec 26 08:26:17 UTC 2009 i686
Intel(R) Atom(TM) CPU N280 @ 1.66GHz GenuineIntel GNU/Linux

The simple command:
$> 9 mount `namespace`/acme /mnt/acme
fails with "mount: only root can do that" and
$> sudo 9 mount `namespace`/acme /tmp/acme
complains about "wrong fs type".

strange, because "9p" filesystem seems to be there:
$> grep 9p /proc/filesystems
nodev   9p

I've also tried sqweek's "9mount" script, but it fails too with an
uninformative "Killed".
$> 9mount 'unix!/tmp/ns.lollo.:0/acme' ~/acme
Killed
The command executed by the script seems to be this one:
$> 9mount -n 'unix!/tmp/ns.lollo.:0/acme' ~/acme
mount -t 9p -o unix,trans=unix,name=lollo,uname=lollo,noextend,nodev
/tmp/ns.lollo.:0/acme /home/lollo/acme
and I've traced down the offending option to be "trans=unix".

Any suggestions?
Thank you!
L.

[-- Attachment #2: Type: text/html, Size: 1472 bytes --]

Re: [9fans] mount acme on plan9port

[Eric Van Hensbergen]

On Sun, Jan 24, 2010 at 7:02 AM, Lorenzo Bolla <lbolla@gmail.com> wrote:
> I'm trying to use "9 mount" to mount acme's socket (in `namespace`/acme) to
> some directory in /mnt (let's say /mnt/acme). I'm using ArchLInux:
> $> uname -a
> Linux eee 2.6.32-ARCH #1 SMP PREEMPT Sat Dec 26 08:26:17 UTC 2009 i686
> Intel(R) Atom(TM) CPU N280 @ 1.66GHz GenuineIntel GNU/Linux
> The simple command:
> mount -t 9p -o unix,trans=unix,name=lollo,uname=lollo,noextend,nodev
> /tmp/ns.lollo.:0/acme /home/lollo/acme
> and I've traced down the offending option to be "trans=unix".
> Any suggestions?

you shouldn't need -o unix,trans=unix -- just trans=unix.
Double check the 9pnet module is installed as well as the 9p module
(it should be automagically in the kernel version you are running).
Also, a good tip when trying to figure out whats going south when v9fs
is involved is to add debug=0xffff into your mount options and post
the respective sections of your /var/log/messages.

Just tried it on 2.6.33-rc4 and it mounted fine
mount -t 9p /tmp/ns.root.localhost:10/acme /mnt -o trans=unix,uname=root

       -eric

Re: [9fans] mount acme on plan9port

[Lorenzo Bolla]

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

On Sun, Jan 24, 2010 at 4:54 PM, Eric Van Hensbergen <ericvh@gmail.com>wrote:

> On Sun, Jan 24, 2010 at 7:02 AM, Lorenzo Bolla <lbolla@gmail.com> wrote:
> > I'm trying to use "9 mount" to mount acme's socket (in `namespace`/acme)
> to
> > some directory in /mnt (let's say /mnt/acme). I'm using ArchLInux:
> > $> uname -a
> > Linux eee 2.6.32-ARCH #1 SMP PREEMPT Sat Dec 26 08:26:17 UTC 2009 i686
> > Intel(R) Atom(TM) CPU N280 @ 1.66GHz GenuineIntel GNU/Linux
> > The simple command:
> > mount -t 9p -o unix,trans=unix,name=lollo,uname=lollo,noextend,nodev
> > /tmp/ns.lollo.:0/acme /home/lollo/acme
> > and I've traced down the offending option to be "trans=unix".
> > Any suggestions?
>
> you shouldn't need -o unix,trans=unix -- just trans=unix.
> Double check the 9pnet module is installed as well as the 9p module
> (it should be automagically in the kernel version you are running).
> Also, a good tip when trying to figure out whats going south when v9fs
> is involved is to add debug=0xffff into your mount options and post
> the respective sections of your /var/log/messages.
>
> Just tried it on 2.6.33-rc4 and it mounted fine
> mount -t 9p /tmp/ns.root.localhost:10/acme /mnt -o trans=unix,uname=root
>
>       -eric
>
>
Thanks for the answer Eric.
9pnet is loaded, as well as 9p.
I've tried to mount both as a user (with sudo) and as root, with no luck.
Here is the messages I get, with debug=0xffff enabled.


Jan 24 17:51:19 eee kernel: *pde = 00000000
Jan 24 17:51:19 eee kernel: Modules linked in: 9p 9pnet fscache usbhid hid
ipv6 ntfs arc4 ecb ath9k snd_seq_dummy mac80211 i915 snd_seq_oss ath
uvcvideo snd_seq_midi_event drm_kms_helper videodev joydev
snd_hda_codec_realtek snd_seq cfg80211 v4l1_compat eeepc_laptop drm
snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss iTCO_wdt
rfkill fan psmouse iTCO_vendor_support i2c_algo_bit snd_mixer_oss snd_pcm
intel_agp uhci_hcd snd_timer ehci_hcd led_class pci_hotplug ac serio_raw
pcspkr i2c_core sg atl1e thermal agpgart processor battery snd usbcore video
output soundcore button snd_page_alloc evdev rtc_cmos rtc_core rtc_lib ext3
jbd mbcache sd_mod ata_piix ata_generic pata_acpi libata scsi_mod
Jan 24 17:51:19 eee kernel:
Jan 24 17:51:19 eee kernel: Pid: 22660, comm: mount Tainted: G      D
 (2.6.32-ARCH #1) 1000HE
Jan 24 17:51:19 eee kernel: EIP: 0060:[<f81144ff>] EFLAGS: 00010246 CPU: 1
Jan 24 17:51:19 eee kernel: EIP is at p9_fid_create+0x6f/0x140 [9pnet]
Jan 24 17:51:19 eee kernel: EAX: 00000001 EBX: f5a247c0 ECX: 00000000 EDX:
00000202
Jan 24 17:51:19 eee kernel: ESI: f627d800 EDI: f5a247dc EBP: f6673000 ESP:
e123fe24
Jan 24 17:51:19 eee kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jan 24 17:51:19 eee kernel: f64c0fb8 00000000 00002000 f5a24540 00000000
f627d800 f6673000 f81155fe
Jan 24 17:51:19 eee kernel: <0> f8115b82 00000023 00000286 e8083f00 00000000
f5a244c6 f5a244ca f64c0fbe
Jan 24 17:51:19 eee kernel: <0> f64c0fb8 c1174cf8 e123feb8 00000000 00000000
f5a24540 f59a9000 00000000
Jan 24 17:51:19 eee kernel: [<f81155fe>] ? p9_client_attach+0x1e/0x110
[9pnet]
Jan 24 17:51:19 eee kernel: [<f8115b82>] ? p9_client_create+0xe2/0x2a0
[9pnet]
Jan 24 17:51:19 eee kernel: [<c1174cf8>] ? match_number+0x88/0xa0
Jan 24 17:51:19 eee kernel: [<f819b044>] ? v9fs_session_init+0x124/0x3d0
[9p]
Jan 24 17:51:19 eee kernel: [<f819909f>] ? v9fs_get_sb+0x4f/0x250 [9p]
Jan 24 17:51:19 eee kernel: [<c10e12d9>] ? vfs_kern_mount+0x69/0x170
Jan 24 17:51:19 eee kernel: [<c10f4f72>] ? get_fs_type+0x32/0xb0
Jan 24 17:51:19 eee kernel: [<c10e143f>] ? do_kern_mount+0x3f/0xe0
Jan 24 17:51:19 eee kernel: [<c10f7ae0>] ? do_mount+0x1f0/0x730
Jan 24 17:51:19 eee kernel: [<c10f5f40>] ? copy_mount_options+0xd0/0x140
Jan 24 17:51:19 eee kernel: [<c10f808e>] ? sys_mount+0x6e/0xa0
Jan 24 17:51:19 eee kernel: [<c10039f3>] ? sysenter_do_call+0x12/0x28
Jan 24 17:51:19 eee kernel: ---[ end trace 3fd7199bdae8deac ]---


Thanks again for you help!
Lorenzo.

[-- Attachment #2: Type: text/html, Size: 4985 bytes --]

Re: [9fans] mount acme on plan9port

[Russ Cox]

plan9port works well with FUSE.
It works less well with the 9p module.

Assuming you have write permission on /mnt/acme
and FUSE installed,

acme -m /mnt/acme

should work just fine.

Russ

Re: [9fans] mount acme on plan9port

[David Leimbach]

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

How about on MacFUSE?  I remember there being some issues there.  In fact,
I'm now using an SSHFS that is *not* a FUSE module, but a pretty nicely done
independent implementation.

Dave

On Sun, Jan 24, 2010 at 11:27 AM, Russ Cox <rsc@swtch.com> wrote:

> plan9port works well with FUSE.
> It works less well with the 9p module.
>
> Assuming you have write permission on /mnt/acme
> and FUSE installed,
>
> acme -m /mnt/acme
>
> should work just fine.
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 790 bytes --]

Re: [9fans] mount acme on plan9port

[Russ Cox]

On Sun, Jan 24, 2010 at 12:09 PM, David Leimbach <leimy2k@gmail.com> wrote:
> How about on MacFUSE?  I remember there being some issues there.  In fact,
> I'm now using an SSHFS that is *not* a FUSE module, but a pretty nicely done
> independent implementation.

The only MacFUSE issues have been using the correct path
since the installed binaries seemed to move around each time
a new version came out.  That seems to have settled down.

Russ

Re: [9fans] mount acme on plan9port

[Ethan Grammatikidis]

On 24 Jan 2010, at 9:51 pm, Russ Cox wrote:

> On Sun, Jan 24, 2010 at 12:09 PM, David Leimbach
> <leimy2k@gmail.com> wrote:
>> How about on MacFUSE?  I remember there being some issues there.
>> In fact,
>> I'm now using an SSHFS that is *not* a FUSE module, but a pretty
>> nicely done
>> independent implementation.
>
> The only MacFUSE issues have been using the correct path
> since the installed binaries seemed to move around each time
> a new version came out.  That seems to have settled down.
>
> Russ
>

Commands may be renamed or missing too. 9pfuse(4) states "The
fusermount binary must exist in the current search path," however the
nearest thing I see to that with macfuse 2.0.2 is:

  $ locate -i mount | grep -i fuse
/System/Library/Filesystems/fusefs.fs/Support/mount_fusefs

Running it I get the nice little mesage: "This program is not meant
to be called directly. The MacFUSE library calls it." Lovely.



--
freedesktop.org, because unix doesn't make things harder enough.

Ethan Grammatikidis
eekee57@fastmail.fm

Re: [9fans] mount acme on plan9port

[Lorenzo Bolla]

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

Anyway, Russ' suggestion worked.
The only weird behaviour is that listing /mnt/acme opens a new empty window
in acme...


On Wed, Jan 27, 2010 at 11:44 AM, Ethan Grammatikidis
<eekee57@fastmail.fm>wrote:

>
> On 24 Jan 2010, at 9:51 pm, Russ Cox wrote:
>
>  On Sun, Jan 24, 2010 at 12:09 PM, David Leimbach <leimy2k@gmail.com>
>> wrote:
>>
>>> How about on MacFUSE?  I remember there being some issues there.  In
>>> fact,
>>> I'm now using an SSHFS that is *not* a FUSE module, but a pretty nicely
>>> done
>>> independent implementation.
>>>
>>
>> The only MacFUSE issues have been using the correct path
>> since the installed binaries seemed to move around each time
>> a new version came out.  That seems to have settled down.
>>
>> Russ
>>
>>
> Commands may be renamed or missing too. 9pfuse(4) states "The fusermount
> binary must exist in the current search path," however the nearest thing I
> see to that with macfuse 2.0.2 is:
>
>  $ locate -i mount | grep -i fuse
> /System/Library/Filesystems/fusefs.fs/Support/mount_fusefs
>
> Running it I get the nice little mesage: "This program is not meant to be
> called directly. The MacFUSE library calls it." Lovely.
>
>
>
> --
> freedesktop.org, because unix doesn't make things harder enough.
>
>
> Ethan Grammatikidis
> eekee57@fastmail.fm
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2205 bytes --]

Re: [9fans] mount acme on plan9port

[roger peppe]

i guess that's because it's walking into mnt/acme/new,
which creates a new window.

i've thought in the past that perhaps the first write
to a file in mnt/acme/new should create the window,
rather than just walking to it.

it always seems odd to me that du -a /mnt has side effects.


2010/1/27 Lorenzo Bolla <lbolla@gmail.com>:
> Anyway, Russ' suggestion worked.
> The only weird behaviour is that listing /mnt/acme opens a new empty window
> in acme...
>
> On Wed, Jan 27, 2010 at 11:44 AM, Ethan Grammatikidis <eekee57@fastmail.fm>
> wrote:
>>
>> On 24 Jan 2010, at 9:51 pm, Russ Cox wrote:
>>
>>> On Sun, Jan 24, 2010 at 12:09 PM, David Leimbach <leimy2k@gmail.com>
>>> wrote:
>>>>
>>>> How about on MacFUSE?  I remember there being some issues there.  In
>>>> fact,
>>>> I'm now using an SSHFS that is *not* a FUSE module, but a pretty nicely
>>>> done
>>>> independent implementation.
>>>
>>> The only MacFUSE issues have been using the correct path
>>> since the installed binaries seemed to move around each time
>>> a new version came out.  That seems to have settled down.
>>>
>>> Russ
>>>
>>
>> Commands may be renamed or missing too. 9pfuse(4) states "The fusermount
>> binary must exist in the current search path," however the nearest thing I
>> see to that with macfuse 2.0.2 is:
>>
>>  $ locate -i mount | grep -i fuse
>> /System/Library/Filesystems/fusefs.fs/Support/mount_fusefs
>>
>> Running it I get the nice little mesage: "This program is not meant to be
>> called directly. The MacFUSE library calls it." Lovely.
>>
>>
>>
>> --
>> freedesktop.org, because unix doesn't make things harder enough.
>>
>> Ethan Grammatikidis
>> eekee57@fastmail.fm
>>
>>
>>
>>
>
>

Re: [9fans] mount acme on plan9port

[erik quanstrom]

On Wed Jan 27 08:42:31 EST 2010, rogpeppe@gmail.com wrote:
> i guess that's because it's walking into mnt/acme/new,
> which creates a new window.
>
> i've thought in the past that perhaps the first write
> to a file in mnt/acme/new should create the window,
> rather than just walking to it.
>
> it always seems odd to me that du -a /mnt has side effects.

seems even more antisocial that fuse is walking
around for no reason.  there's a fine line between
programs doing things for you and to you.

- erik

Re: [9fans] mount acme on plan9port

[roger peppe]

fuse is probably just doing a stat of each file, as is
conventional and necessary in unix.

the 9p fuse converter can't legitimately cache the
qids from the directory read, so there's probably
no other way.

2010/1/27 erik quanstrom <quanstro@quanstro.net>:
> On Wed Jan 27 08:42:31 EST 2010, rogpeppe@gmail.com wrote:
>> i guess that's because it's walking into mnt/acme/new,
>> which creates a new window.
>>
>> i've thought in the past that perhaps the first write
>> to a file in mnt/acme/new should create the window,
>> rather than just walking to it.
>>
>> it always seems odd to me that du -a /mnt has side effects.
>
> seems even more antisocial that fuse is walking
> around for no reason.  there's a fine line between
> programs doing things for you and to you.
>
> - erik
>
>

Re: [9fans] mount acme on plan9port

[Eric Van Hensbergen]

Thanks for generating the debug trace, that's a wacky place for a
problem, fidcreate should just be allocating resources.  I'll try and
reproduce and add it to the bug list.  There were some latent boofhead
bugs in the option parsing code -- its possible that there's one in
the trans_fd option parsing that is overflowing a buffer and
corrupting memory.

Thanks Again,

      -eric


On Sun, Jan 24, 2010 at 11:55 AM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>
>
> On Sun, Jan 24, 2010 at 4:54 PM, Eric Van Hensbergen <ericvh@gmail.com>
> wrote:
>>
>> On Sun, Jan 24, 2010 at 7:02 AM, Lorenzo Bolla <lbolla@gmail.com> wrote:
>> > I'm trying to use "9 mount" to mount acme's socket (in `namespace`/acme)
>> > to
>> > some directory in /mnt (let's say /mnt/acme). I'm using ArchLInux:
>> > $> uname -a
>> > Linux eee 2.6.32-ARCH #1 SMP PREEMPT Sat Dec 26 08:26:17 UTC 2009 i686
>> > Intel(R) Atom(TM) CPU N280 @ 1.66GHz GenuineIntel GNU/Linux
>> > The simple command:
>> > mount -t 9p -o unix,trans=unix,name=lollo,uname=lollo,noextend,nodev
>> > /tmp/ns.lollo.:0/acme /home/lollo/acme
>> > and I've traced down the offending option to be "trans=unix".
>> > Any suggestions?
>>
>> you shouldn't need -o unix,trans=unix -- just trans=unix.
>> Double check the 9pnet module is installed as well as the 9p module
>> (it should be automagically in the kernel version you are running).
>> Also, a good tip when trying to figure out whats going south when v9fs
>> is involved is to add debug=0xffff into your mount options and post
>> the respective sections of your /var/log/messages.
>>
>> Just tried it on 2.6.33-rc4 and it mounted fine
>> mount -t 9p /tmp/ns.root.localhost:10/acme /mnt -o trans=unix,uname=root
>>
>>       -eric
>>
>
> Thanks for the answer Eric.
> 9pnet is loaded, as well as 9p.
> I've tried to mount both as a user (with sudo) and as root, with no luck.
> Here is the messages I get, with debug=0xffff enabled.
>
> Jan 24 17:51:19 eee kernel: *pde = 00000000
> Jan 24 17:51:19 eee kernel: Modules linked in: 9p 9pnet fscache usbhid hid
> ipv6 ntfs arc4 ecb ath9k snd_seq_dummy mac80211 i915 snd_seq_oss ath
> uvcvideo snd_seq_midi_event drm_kms_helper videodev joydev
> snd_hda_codec_realtek snd_seq cfg80211 v4l1_compat eeepc_laptop drm
> snd_seq_device snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss iTCO_wdt
> rfkill fan psmouse iTCO_vendor_support i2c_algo_bit snd_mixer_oss snd_pcm
> intel_agp uhci_hcd snd_timer ehci_hcd led_class pci_hotplug ac serio_raw
> pcspkr i2c_core sg atl1e thermal agpgart processor battery snd usbcore video
> output soundcore button snd_page_alloc evdev rtc_cmos rtc_core rtc_lib ext3
> jbd mbcache sd_mod ata_piix ata_generic pata_acpi libata scsi_mod
> Jan 24 17:51:19 eee kernel:
> Jan 24 17:51:19 eee kernel: Pid: 22660, comm: mount Tainted: G      D
>  (2.6.32-ARCH #1) 1000HE
> Jan 24 17:51:19 eee kernel: EIP: 0060:[<f81144ff>] EFLAGS: 00010246 CPU: 1
> Jan 24 17:51:19 eee kernel: EIP is at p9_fid_create+0x6f/0x140 [9pnet]
> Jan 24 17:51:19 eee kernel: EAX: 00000001 EBX: f5a247c0 ECX: 00000000 EDX:
> 00000202
> Jan 24 17:51:19 eee kernel: ESI: f627d800 EDI: f5a247dc EBP: f6673000 ESP:
> e123fe24
> Jan 24 17:51:19 eee kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Jan 24 17:51:19 eee kernel: f64c0fb8 00000000 00002000 f5a24540 00000000
> f627d800 f6673000 f81155fe
> Jan 24 17:51:19 eee kernel: <0> f8115b82 00000023 00000286 e8083f00 00000000
> f5a244c6 f5a244ca f64c0fbe
> Jan 24 17:51:19 eee kernel: <0> f64c0fb8 c1174cf8 e123feb8 00000000 00000000
> f5a24540 f59a9000 00000000
> Jan 24 17:51:19 eee kernel: [<f81155fe>] ? p9_client_attach+0x1e/0x110
> [9pnet]
> Jan 24 17:51:19 eee kernel: [<f8115b82>] ? p9_client_create+0xe2/0x2a0
> [9pnet]
> Jan 24 17:51:19 eee kernel: [<c1174cf8>] ? match_number+0x88/0xa0
> Jan 24 17:51:19 eee kernel: [<f819b044>] ? v9fs_session_init+0x124/0x3d0
> [9p]
> Jan 24 17:51:19 eee kernel: [<f819909f>] ? v9fs_get_sb+0x4f/0x250 [9p]
> Jan 24 17:51:19 eee kernel: [<c10e12d9>] ? vfs_kern_mount+0x69/0x170
> Jan 24 17:51:19 eee kernel: [<c10f4f72>] ? get_fs_type+0x32/0xb0
> Jan 24 17:51:19 eee kernel: [<c10e143f>] ? do_kern_mount+0x3f/0xe0
> Jan 24 17:51:19 eee kernel: [<c10f7ae0>] ? do_mount+0x1f0/0x730
> Jan 24 17:51:19 eee kernel: [<c10f5f40>] ? copy_mount_options+0xd0/0x140
> Jan 24 17:51:19 eee kernel: [<c10f808e>] ? sys_mount+0x6e/0xa0
> Jan 24 17:51:19 eee kernel: [<c10039f3>] ? sysenter_do_call+0x12/0x28
> Jan 24 17:51:19 eee kernel: ---[ end trace 3fd7199bdae8deac ]---
>
> Thanks again for you help!
> Lorenzo.
>
>
>

Re: [9fans] mount acme on plan9port

[erik quanstrom]

On Wed Jan 27 09:37:02 EST 2010, rogpeppe@gmail.com wrote:
> fuse is probably just doing a stat of each file, as is
> conventional and necessary in unix.
>
> the 9p fuse converter can't legitimately cache the
> qids from the directory read, so there's probably
> no other way.

why is it walking there in the first place?  i might
be able to understand fuse reading the top level
directory.  but new isn't even at the top level.

- erik

Re: [9fans] mount acme on plan9port

[Eric Van Hensbergen]

reflection of Linux VFS operations into 9P is often a strange and
interesting experience.

      -eric


On Wed, Jan 27, 2010 at 3:20 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Wed Jan 27 09:37:02 EST 2010, rogpeppe@gmail.com wrote:
>> fuse is probably just doing a stat of each file, as is
>> conventional and necessary in unix.
>>
>> the 9p fuse converter can't legitimately cache the
>> qids from the directory read, so there's probably
>> no other way.
>
> why is it walking there in the first place?  i might
> be able to understand fuse reading the top level
> directory.  but new isn't even at the top level.
>
> - erik
>
>

Re: [9fans] mount acme on plan9port

[ron minnich]

On Wed, Jan 27, 2010 at 1:35 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> reflection of Linux VFS operations into 9P is often a strange and
> interesting experience.


Wish I could find Lucho's email on this, but the Linux guys
particularly don't like things like clone files; "Our scripts will
read them and cause trouble" is the basic complaint.

Bringing some of these new ideas to older OSes will hit some
incompatibilities that can't be fixed ...

ron

Re: [9fans] mount acme on plan9port

[Charles Forsyth]

>"Our scripts will read them and cause trouble" is the basic complaint.

unlike reading all those harmless files in /dev with no side-effects whatsoever

Re: [9fans] mount acme on plan9port

[Russ Cox]

> why is it walking there in the first place?  i might
> be able to understand fuse reading the top level
> directory.  but new isn't even at the top level.

yes it is.  /mnt/acme is the root, hence /mnt/acme/new
is in the top level.

ls -l /mnt/acme

does a directory read to obtain just the names of the
directory entries (that's all the unix interface allows)
and then stats each file in the directory, which turns
into a 9p walk+stat+clunk.

if you ran ls -l /mnt/acme/* in plan 9 you'd get the
same behavior.  the difference is that 9p has
optimized the star-free case in a way that unix
cannot take advantage of.

russ

Re: [9fans] mount acme on plan9port

[roger peppe]

2010/1/28 Russ Cox <rsc@swtch.com>:
> if you ran ls -l /mnt/acme/* in plan 9 you'd get the
> same behavior.  the difference is that 9p has
> optimized the star-free case in a way that unix
> cannot take advantage of.

ls -ld /mnt/acme/* would be a better illustration, i think.