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