[haiku-commits] Re: r35152 - haiku/trunk/src/add-ons/kernel/file_systems/netfs/shared
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 19 Jan 2010 13:23:32 +0000
Hi Stephan
> On 2010-01-19 at 03:41:06 [+0100], mmlr@xxxxxxxx wrote:
> > Author: mmlr
> > Date: 2010-01-19 03:41:06 +0100 (Tue, 19 Jan 2010) New Revision:
> > 35152
> > Changeset: http://dev.haiku-os.org/changeset/35152/haiku
> >
> > Modified:
> > haiku/trunk/src/add-
> > ons/kernel/file_systems/netfs/shared/FSObject.cpp
> > Log:
> > The default for deleteWhenUnreferenced changed between the
> > Referencable
> > of the old userlandfs and the BReferenceable now in use by netfs.
> > So
> > better explicitly set that to avoid nasty surprises (like crashes
> > left
> > and right).
>
> Thanks a lot. I actually made a mental note to check up on
> BReferenceable
> changes and even did, but I just checked the meaning of the parameter
> and
> forgot about the default value. :-D
Mental notes ;-) Took me a while to figure this one out. Had it
narrowed down to reference counting problems in the end and after a
while it occured to me to check if the referenceable implementations
actually were the same...
> 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.
> 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've also noticed that typeahead searching in Tracker takes a very long
time initially and produces a lot of network traffic, almost as if it
was re-loading all the attributes once again. Later use of typeahead
searching is then snappy. Overall this imposes a very long initial time
to populate and make the music library usable. I'd like to get that a
bit more usable performance-wise if at all possible.
> NetFSServer and
> AuthenticationServer could be renamed to netfs_server and
> authentication_server and be placed in /system/servers. netfs_config
> could
> go into /system/bin (although I have no idea what it is really for).
I'd welcome the renaming, as the current names look out of place indeed.
I gather that netfs_config is to explicitly add/remove servers from the
list. It seems that the automatic discovery works fine though so that
you don't usually need it. Considering the possibility of unannounced
"hidden" servers we might want to keep it though.
Another thing that I've noticed is that resources for the servers seem
to be missing. For one this makes NetFSServerPrefs unable to launch
NetFSServer due to the missing app sig and it also makes them
foreground apps by default so NetFSServer and AuthenticationServer show
up in the Deskbar by default.
> 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.
I was planning on documenting how to set up a netfs via a blog post at
haiku-os.org today so that others don't have to figure out how these
parts all fit together. Took me a while to understand how it was meant
to work (and to fix the issues ;-)
Regards
Michael
Other related posts:
