[OmniOS-discuss] Best way to share files with Mac?

[Stephan Budach]

Hi,

----- Ursprüngliche Mail -----
> Von: "Geoff Nordli" <geoffn at gnaa.net>
> An: "Chris Ferebee" <cf at ferebee.net>
> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
> Gesendet: Sonntag, 26. November 2017 07:54:20
> Betreff: Re: [OmniOS-discuss] Best way to share files with Mac?
> 
> Hi Chris.
> 
> I wonder if now this is fixed with the vfs_fruit module in Samba.
> 
> http://plazko.io/apple-osx-finder-is-listing-files-very-very-slow-when-connected-to-smb-shared-hard-drive-connected-to-a-wifi-router/
> 
> thanks,
> 
> Geoff
> 

the vfs_fruit extension, afair, provides interlocking capabilities between Netatalk/AFP and Samba 3/4. It allows Macs and PCs to share the same data through both protocols.

Looking at the man page of it, it may be doing some more stuff, which may come in handy for macOS clients. However, this module will not work with the kernel/smb and you will have to go with a full-fledged Samba 4 installation.

I know Ralph Böhme, the author of vfs_fruit, and I have contacted serNet (the company he's working for) and we be having a conversation about what the odds arem that they provide a package for omniOS as well.

Cheers,
Stephan
  
> 
> 
> On 2017-11-25 06:45 AM, Chris Ferebee wrote:
> > Hi Geoff,
> >
> > I love the way you put this:
> >
> >> They are reporting problems with the speed when using the
> >> "finder".
> > Oh, yes. I spent months of my life in 2014 fighting the Finder vs.
> > a major installation of netatalk, which I deployed on SmartOS.
> >
> > We have a large server (dual 6-core XEON, 128 GB RAM, 22 x 4 TB
> > SAS, STEC ZeusRAM) running as a fileserver for Macs. The client
> > does motion graphics and has a very large number of files, 100+
> > million on the largest share. (Not more than a few thousand files
> > per directory, though.)
> >
> > What we saw was that opening the Finder to a directory on the AFP
> > share would show a blank window for 20–180 seconds before
> > displaying the contents, even if there were maybe just 10–20
> > subdirectories to display.
> >
> > Then, as long as the Finder window was open, it would peg one CPU
> > core on the server at 100%, even though the display did not
> > change.
> >
> > It turned out that the Finder was looping continually through files
> > several subdirectories deep, querying extended attributes. Due to
> > the way netatalk is coded, this requires a call to getcwd() each
> > time, which is very expensive on Solaris. (getcwd() = get the path
> > name of the current working directory.)
> >
> > A SmartOS engineer was kind enough to advise me on this, and
> > basically told me: if you have getcwd() in your hot path, you are
> > screwed. This is probably a reason why the problem, though
> > actually a netatalk issue, is less pronounced on Linux, where
> > getcwd() is not as expensive as on Solaris.
> >
> > I never did get to the bottom of this. It appears that it doesn’t
> > happen when the Finder is talking to Apple’s own AFP server,
> > perhaps because there the Finder is able to use FSEvents to track
> > changes. Unfortunately, it appears that netatalk has never fully
> > addressed this, at least I haven’t seen anything indicating that
> > it has gained FSEvents supports in the past years. Here is what
> > netatalk dev Ralph Böhme had to say:
> >
> > 	<https://sourceforge.net/p/netatalk/mailman/message/32669188/>
> >
> > In the end, I switched the client to a (commercial, expensive) AFP
> > server, HELIOS EtherShare, and all problems went away, performance
> > as expected, and I didn’t investigate further.
> >
> > If you are dealing with Adobe applications, be aware that there are
> > a number of reasons why they do not work well on a Mac over SMB.
> > We didn’t get past a hard maximum path length of 254 characters,
> > but there are others.
> >
> > I’m happy to discuss this further, and would be quite interested to
> > find a less-expensive solution for large-scale file service for
> > Macs. We can take it off-list if it goes any further off topic.
> >
> > Good luck,
> > Chris
> >
> >
> >> Am 24.11.2017 um 03:56 schrieb Geoff Nordli <geoffn at gnaa.net>:
> >>
> >> Hi.
> >>
> >> I have to support a few mac machines connecting to a few file
> >> shares running Omnios.
> >>
> >> They are reporting problems with the speed when using the
> >> "finder".
> >>
> >> I see there is a netatalk package I can download and compile off
> >> of sourceforge, which looks fairly current.
> >>
> >> Any suggestions on the best way forward to support Mac machines?
> >>
> >> thanks,
> >>
> >> Geoff
> >>
> >>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5546 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20171126/0d253587/attachment-0001.bin>