On Wed, Apr 25, 2012 at 9:07 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Wed, Apr 25, 2012 at 7:37 PM, Richard Elling
> <richard.ell...@gmail.com> wrote:
>> On Apr 25, 2012, at 3:36 PM, Nico Williams wrote:
>> > I disagree vehemently. automount is a disaster because you need to
>> > synchronize changes with all those clients. That's not realistic.
>> Really? I did it with NIS automount maps and 600+ clients back in 1991.
>> Other than the obvious problems with open files, has it gotten worse since
> Nothing's changed. Automounter + data migration -> rebooting clients
> (or close enough to rebooting). I.e., outage.
Uhhh, not if you design your automounter architecture correctly
and (as Richard said) have NFS clients that are not lame to which I'll
add, automunters that actually work as advertised. I was designing
automount architectures that permitted dynamic changes with minimal to
no outages in the late 1990's. I only had a little over 100 clients
(most of which were also servers) and NIS+ (NIS ver. 3) to distribute
the indirect automount maps.
I also had to _redesign_ a number of automount strategies that
were built by people who thought that using direct maps for everything
was a good idea. That _was_ a pain in the a** due to the changes
needed at the applications to point at a different hierarchy.
It all depends on _what_ the application is doing. Something that
opens and locks a file and never releases the lock or closes the file
until the application exits will require a restart of the application
with an automounter / NFS approach.
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
-> Technical Advisor, RPI Players
zfs-discuss mailing list