On Wed, Apr 25, 2012 at 8:57 PM, Paul Kraus <pk1...@gmail.com> wrote:
> On Wed, Apr 25, 2012 at 9:07 PM, Nico Williams <n...@cryptonector.com> wrote:
>> 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.

Further below you admit that you're talking about read-only data,
effectively.  But the world is not static.  Sure, *code* is by and
large static, and indeed, we segregated data by whether it was
read-only (code, historical data) or not (application data, home
directories).  We were able to migrated *read-only* data with no
outages.  But for the rest?  Yeah, there were always outages.  Of
course, we had a periodic maintenance window, with all systems
rebooting within a short period, and this meant that some data
migration outages were not noticeable, but they were real.

>    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.

We used indirect maps almost exclusively.  Moreover, we used
hierarchical automount entries, and even -autofs mounts.  We also used
environment variables to control various things, such as which servers
to mount what from (this was particularly useful for spreading the
load on read-only static data).  We used practically every feature of
the automounter except for executable maps (and direct maps, when we
eventually stopped using those).

>    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.

No kidding!  In the real world such applications exist and get used.

zfs-discuss mailing list

Reply via email to