[haiku-commits] Re: r35152 - haiku/trunk/src/add-ons/kernel/file_systems/netfs/shared
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 19 Jan 2010 15:24:59 +0100
On 2010-01-19 at 14:23:32 [+0100], Michael Lotz <mmlr@xxxxxxxx> wrote:
> > With these changes, I am able to mount shares. I actually thought
> > that it
> > wouldn't work yet, because of stat versus beos_stat, but it appears,
> > Ingo
> > already took care of that for BeOS R5 file systems in UserlandFS. At
> > least
> > it doesn't seem to give problems.
>
> It seems to work, even though it expects the BeOS format. I think it
> should be changed to stat_beos, though possibly through the source
> compatibility macros it actually falls into place.
Indeed, BeOSKernelVolume::ReadStat() do actually need to convert between
the stat structures and when compiling the client FS the BeOS compatible
stat structure needs to be enforced. Only because neither is done, things
seem to work.
> > Michael, what are your experiences so far, does netfs work reliably
> > for
> > you? For me, it seems to be the case so far. We could make an
> > OptionalPackage for the various components.
>
> Works just fine so far, but I'm only using it read-only for now. I use
> it to access the music library of the pc downstairs from my new
> mediacenter (something I always wanted to work, therefore diving into
> these issues). The only issue I have is performance. Populating the
> music dir (5k files) takes several minutes and definitely doesn't
> saturate the connections. It maxes out at some 30kb/s where actual
> reading when opening a file then does 600kb/s just fine. I take it
> that's due to many individual calls to read the nodes and attributes.
I wouldn't rule that out, though there should already be quite a bit of
batching and caching going on. E.g. attribute directories including the
data of small attributes (currently 8 bytes, cf.
server/AttributeDirectory.cpp) should be read in one go. If you have
several attributes per node that are not small and Tracker reads them, that
would cause considerably more network traffic, though.
Generally userlandfs based file systems won't win any performance
competition anyway. The FS interface hooks are forwarded one-to-one and the
communication happens via ports, so there's quite a bit of overhead.
Finally the R5 FS interface mapping doesn't come for free either. Some
hooks require additional work, and it also doesn't help that, obviously,
none of the caches introduced in Haiku (file and directory entry cache) are
used.
> > A
> > dependency to the UserlandFS OptionalPackage could be added. I am
> > also
> > wondering if the code should be pulled apart, or if it should all
> > stay in
> > the netfs file_system add-on folder. On the one hand it's nice to
> > have it
> > all in one place, but most parts of the code are misplaced looking
> > from
> > another perspective. Opinions?
>
> I kinda like having it all in one place. And I wouldn't know where else
> to put the other parts, but if you find a nice place for them please go
> ahead and move. In the end you're going to build them by target name or
> through the optional package, so nobody will really care where they are
> located.
Yep, it's just more convenient to browse when everything is in one place.
CU, Ingo
Other related posts:
