zfs discuss - May 2008 - Per-user home filesystems and OS-X Leopard anomaly

I encountered an issue that people using OS-X systems as NFS clients 
need to be aware of.  While not strictly a ZFS issue, it may be 
encounted most often by ZFS users since ZFS makes it easy to support 
and export per-user filesystems.  The problem I encountered was when 
using ZFS to create exported per-user filesystems and the OS-X 
automounter to perform the necessary mount magic.

OS-X creates hidden ".DS_Store" directories in every directory which 
is accessed (http://en.wikipedia.org/wiki/.DS_Store).

OS-X decided that it wanted to create the path "/home/.DS_Store" and 
it would not take `no'' for an answer.  First it would try to create 
"/home/.DS_Store" and then it would try an alternate name.  Since the 
automounter was used, there would be an automount request for 
"/home/.DS_Store", which does not exist on the server so the mount 
request would fail.  Since OS-X does not take ''no'' for an
answer,
there would be subsequent thousands of back to back mount requests. 
The end result was that ''mountd'' was one of the top three
resource
consumers on my system, there would be bursts of high network traffic 
(1500 packets/second), and the affected OS-X system would operate 
more strangely than normal.

The simple solution was to simply create a "/home/.DS_Store" directory
on the server so that the mount request would succeed.

Bob
=====================================Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On May 21, 2008, at 11:15 AM, Bob Friesenhahn wrote:
> I encountered an issue that people using OS-X systems as NFS clients
> need to be aware of.  While not strictly a ZFS issue, it may be
> encounted most often by ZFS users since ZFS makes it easy to support
> and export per-user filesystems.  The problem I encountered was when
> using ZFS to create exported per-user filesystems and the OS-X
> automounter to perform the necessary mount magic.
>
> OS-X creates hidden ".DS_Store" directories in every directory
which
> is accessed (http://en.wikipedia.org/wiki/.DS_Store).
>
> OS-X decided that it wanted to create the path "/home/.DS_Store"
and
> it would not take `no'' for an answer.  First it would try to
create
> "/home/.DS_Store" and then it would try an alternate name.  Since
the
> automounter was used, there would be an automount request for
> "/home/.DS_Store", which does not exist on the server so the
mount
> request would fail.  Since OS-X does not take ''no'' for an
answer,
> there would be subsequent thousands of back to back mount requests.
> The end result was that ''mountd'' was one of the top three
resource
> consumers on my system, there would be bursts of high network traffic
> (1500 packets/second), and the affected OS-X system would operate
> more strangely than normal.
>
> The simple solution was to simply create a "/home/.DS_Store"
directory
> on the server so that the mount request would succeed.
Did you try this?
http://support.apple.com/kb/HT1629

-Andy
>
>
> Bob
> =====================================> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us,
http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

zfs-discuss-bounces at opensolaris.org wrote on 05/21/2008 10:38:10 AM:
>
> On May 21, 2008, at 11:15 AM, Bob Friesenhahn wrote:
>
> > I encountered an issue that people using OS-X systems as NFS clients
> > need to be aware of.  While not strictly a ZFS issue, it may be
> > encounted most often by ZFS users since ZFS makes it easy to support
> > and export per-user filesystems.  The problem I encountered was when
> > using ZFS to create exported per-user filesystems and the OS-X
> > automounter to perform the necessary mount magic.
> >
> > OS-X creates hidden ".DS_Store" directories in every
directory which
> > is accessed (http://en.wikipedia.org/wiki/.DS_Store).
> >
> > OS-X decided that it wanted to create the path
"/home/.DS_Store" and
> > it would not take `no'' for an answer.  First it would try to
create
> > "/home/.DS_Store" and then it would try an alternate name. 
Since the
> > automounter was used, there would be an automount request for
> > "/home/.DS_Store", which does not exist on the server so the
mount
> > request would fail.  Since OS-X does not take ''no''
for an answer,
> > there would be subsequent thousands of back to back mount requests.
> > The end result was that ''mountd'' was one of the top
three resource
> > consumers on my system, there would be bursts of high network traffic
> > (1500 packets/second), and the affected OS-X system would operate
> > more strangely than normal.
> >
> > The simple solution was to simply create a "/home/.DS_Store"
directory
> > on the server so that the mount request would succeed.
>
> Did you try this?
> http://support.apple.com/kb/HT1629
>
> -Andy
>
Andy,

      That change does indeed turn off the .DS_Store creation.  There are
side effects to this change that may or may not be acceptable to you in
different environments.  Some of them are:

* No extended resource information is stored for files.
* Folder and File coloring/placement/comments/etc are not stored.
* Some mac apps (still!) use this resource fork data section is silly and
unexpected ways (hiding real data outside of the file).

      In our case,  it made sense to disable.  We did have users complain
about the loss of sorting or per folder settings though.

-Wade

On Wed, 21 May 2008, Andy Lubel wrote:
>> The simple solution was to simply create a "/home/.DS_Store"
directory
>> on the server so that the mount request would succeed.
>
> Did you try this?
> http://support.apple.com/kb/HT1629
No, I decided not to use that since it has negative impact on OS-X 
applications and a few .DS_Store files don''t bother me.  I was a bit 
dubious that it would even work since I have had OS-X on the network 
for three years now and have noticed that each OS-X release (Panther, 
Tiger, Leopard) behaves quite differently.

Obviously a "/home/.DS_Store" directory can not store the file content
that OS-X planned to put there but it makes the mountd problem go 
away. :-)

Bob
=====================================Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On May 21, 2008, at 11:15, Bob Friesenhahn wrote:
> The simple solution was to simply create a "/home/.DS_Store"
directory
> on the server so that the mount request would succeed.
What permissions do you have on /home/.DS_Store?  I assume the  
clients fail quietly on their write attempts?

Does the setup work well aside from this problem?  I''ve just been  
mulling AFP vs. NFS vs. iSCSI for Mac clients to their ZFS homes, and  
AFP is the one I tried first and have ruled out as usable. :)

BTW, you should probably file a bug with Apple on this:

   https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/wa/signIn

They''ll have ZFS on OSX Server eventually.  If you don''t want
to
create an ADC account I can put one in for you (though less  
efficient, obviously).

-Bill

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

On Wed, 21 May 2008, Bill McGonigle wrote:
>
> What permissions do you have on /home/.DS_Store?  I assume the clients fail
> quietly on their write attempts?
The actual permissions do not seem to matter.  The directory does not 
need to be writeable.  As long as the path can be mounted, the problem 
seems to be solved.  OS-X will not write anything there since it wants 
to write a file rather than write into a directory.
> Does the setup work well aside from this problem?  I''ve just been
mulling AFP
> vs. NFS vs. iSCSI for Mac clients to their ZFS homes, and AFP is the one I 
> tried first and have ruled out as usable. :)
I can''t speak from a Mac-centric view, but for my purposes NFS in 
Leopard works well.  The automounter in Leopard is a perfect clone of 
the Solaris automounter, and may be based on OpenSolaris code.
> BTW, you should probably file a bug with Apple on this:
>
> https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/wa/signIn
>
> They''ll have ZFS on OSX Server eventually.  If you don''t
want to create an
> ADC account I can put one in for you (though less efficient, obviously).
Feel free to do so on my behalf. :-)

Bob
=====================================Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Bob Friesenhahn wrote:
> I can''t speak from a Mac-centric view, but for my purposes NFS in 
> Leopard works well.  The automounter in Leopard is a perfect clone of 
> the Solaris automounter, and may be based on OpenSolaris code.
It is based on osol code.  The implementor worked a long time at Sun :-)

Rob T

On May 21, 2008, at 13:43, Bob Friesenhahn wrote:
>> BTW, you should probably file a bug with Apple on this:
>>
>> https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/wa/signIn
>>
>> They''ll have ZFS on OSX Server eventually.  If you
don''t want to
>> create an ADC account I can put one in for you (though less  
>> efficient, obviously).
>
> Feel free to do so on my behalf. :-)
Better late then never... this is now bug #5989285 (not that this  
will help most people; they''re not open).

-Bill
-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

> I encountered an issue that people using OS-X systems
> as NFS clients 
> need to be aware of.  While not strictly a ZFS issue,
> it may be 
> encounted most often by ZFS users since ZFS makes it
> easy to support 
> and export per-user filesystems.  The problem I
> encountered was when 
> using ZFS to create exported per-user filesystems and
> the OS-X 
> automounter to perform the necessary mount magic.
> 
> OS-X creates hidden ".DS_Store" directories in every
> directory which 
> is accessed (http://en.wikipedia.org/wiki/.DS_Store).
> 
> OS-X decided that it wanted to create the path
> "/home/.DS_Store" and 
> it would not take `no'' for an answer.  First it would
> try to create 
> "/home/.DS_Store" and then it would try an alternate
> name.  Since the 
> automounter was used, there would be an automount
> request for 
> "/home/.DS_Store", which does not exist on the server
> so the mount 
> request would fail.  Since OS-X does not take ''no''
> for an answer, 
> there would be subsequent thousands of back to back
> mount requests. 
> The end result was that ''mountd'' was one of the top
> three resource 
> consumers on my system, there would be bursts of high
> network traffic 
> (1500 packets/second), and the affected OS-X system
> would operate 
> more strangely than normal.
> 
> The simple solution was to simply create a
> "/home/.DS_Store" directory 
> on the server so that the mount request would
> succeed.
Too bad it appears to be non-obvious how to do loopback mounts
(a mount of one local directory onto another, without having to be an
NFS server) on Darwin/MacOS X; then you could mount the
/home/.DS_Store locally from a directory elsewhere (e.g.
/export/home/.DS_Store) on each machine, rather than bothering
the server with it.
 
 
This message posted from opensolaris.org

On 5/21/08 12:43 PM, "Bob Friesenhahn" <bfriesen at
simple.dallas.tx.us> wrote:
> I can''t speak from a Mac-centric view, but for my purposes NFS in
> Leopard works well.  The automounter in Leopard is a perfect clone of
> the Solaris automounter, and may be based on OpenSolaris code.
I had heard it was, and I have to concur.  Leopard is the first OS X
automounter that actually works as expected.  There was zero fiddling with
our Solaris 10U5 NFS server (a Thumper).

Charles

-----

Charles Soto                        charles.soto at austin.utexas.edu
Director, Information Technology? ? ? ??         TEL: 512-740-1888
The University of Texas at Austin?? ?? ?         FAX: 512-475-9711
College of Communication, CMA 5.150G
1 University Station A0900, Austin, TX 78712
http://communication.utexas.edu/technology/

On Jun 5, 2008, at 17:03, Bill McGonigle wrote:
> Better late then never... this is now bug #5989285 (not that this
> will help most people; they''re not open).
Apple say:

   After further investigation it has been determined that this is
   a known issue, which is currently being investigated by engineering.
   This issue has been filed in our bug database under the original
   Bug ID# 5952818.

So, somebody already knew about it, and they haven''t rejected the  
bug, so it might get fixed sooner or later.

-Bill

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf

On May 21, 2008, at 13:14, Bill McGonigle wrote:
> They''ll have ZFS on OSX Server eventually.
Replying to myself again... :P

It looks like ''eventually'' is next year:
   http://www.apple.com/server/macosx/snowleopard/

   "ZFS

   For business-critical server deployments, Snow Leopard
   Server adds read and write support for the high-performance,
   128-bit ZFS file system, which includes advanced features
   such as storage pooling, data redundancy, automatic error
   correction, dynamic volume expansion, and snapshots."

I guess it''ll trickle down to ''Client'' in the
subsequent revision.
It''ll be there via diskutil or something in Snow Leopard, if it  
follows historical trends, just not in the GUI - I think they like  
the alpha geeks to beat on new filesystem stuff for them this way. :)

-Bill

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf