----- Original Message -----
From: “Arthur Kreitman”
To: “File Systems Developers”
Sent: Monday, April 22, 2002 9:56 PM
Subject: [ntfsd] Re: How to share storage device on logical block acce ss
level?
> The cluster file system was famous for its distributed lock problems. VMS
> may had been successful, but the cluster file system wasn’t.
Bzzzt! FUD alert!
The cluster file system was indeed famous, but not for any problems. The
closest anyone came to being able to knock the DLM was because a cluster
state transition could take up to a minute (in early versions) to detect
node failure and rebuild the distributed lock database - about the same
length of time most of the competition (that had clustering at all) was
still struggling to achieve just a couple of years ago, while VMS’s times
had been improved to a matter of a few seconds by the early '90s.
Of course, these criticisms came from competitors who had no comparable
facility at all to offer at the time (or for at least a decade later), so
they could perhaps be forgiven for grasping at any straw they thought might
not break instantly. They also liked to criticize the theoretical
scalability of the DLM approach - but, again, VMS has supported clusters up
to 96 nodes for a very long time and customers have successfully run
considerably larger ones, while most competitors have had to boast about
their 2-to-4-node clusters until very recently, so their claims sound a bit
hollow in this area as well.
Be all that as it may, VMS, and VMS clusters, were indisputably king of
their not-insignificant hill for a lengthy period both before and after VMS
clusters appeared in 1984. And since the VMS cluster file system was the
only file system available on the platform, suggesting that it was anything
less than fully-usable is rather silly.
Or are you claiming personal experience in this area? If so, please
elaborate: it certainly would seem to differ from my own.
- bill
Um, I do have some personal experience with VAXClusters, and we found
that, for highly available systems (power management control systems),
VAXClusters would check out for far too long to be usable (on the order
of minutes, not seconds). This was in 1988; word-of-mouth from the
company I was at said things got better, but not good enough, later.
Bottom line in the VAXCluster world was that they would handle
well-characterized transitions quite well, but did not handle nasty
stuff at all well (things like pulling power on an HSC50 without
warning). Perhaps we were asking too much of the clusters at the time.
We ultimately worked around the cluster state transition problems (which
were, ultimately, DLM state transitions) by failing over from one
cluster to another, as opposed to from one cluster node to another. Sort
of negated some of the benfits of the clusters…
…dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill Todd
Sent: Monday, April 22, 2002 9:07 PM
To: File Systems Developers
Subject: [ntfsd] Re: How to share storage device on logical block acce
ss level?
----- Original Message -----
From: “Arthur Kreitman”
To: “File Systems Developers”
Sent: Monday, April 22, 2002 9:56 PM
Subject: [ntfsd] Re: How to share storage device on logical block acce
ss level?
> The cluster file system was famous for its distributed lock problems.
> VMS may had been successful, but the cluster file system wasn’t.
Bzzzt! FUD alert!
The cluster file system was indeed famous, but not for any problems.
The closest anyone came to being able to knock the DLM was because a
cluster state transition could take up to a minute (in early versions)
to detect node failure and rebuild the distributed lock database - about
the same length of time most of the competition (that had clustering at
all) was still struggling to achieve just a couple of years ago, while
VMS’s times had been improved to a matter of a few seconds by the early
'90s.
Of course, these criticisms came from competitors who had no comparable
facility at all to offer at the time (or for at least a decade later),
so they could perhaps be forgiven for grasping at any straw they thought
might not break instantly. They also liked to criticize the
theoretical scalability of the DLM approach - but, again, VMS has
supported clusters up to 96 nodes for a very long time and customers
have successfully run considerably larger ones, while most competitors
have had to boast about their 2-to-4-node clusters until very recently,
so their claims sound a bit hollow in this area as well.
Be all that as it may, VMS, and VMS clusters, were indisputably king of
their not-insignificant hill for a lengthy period both before and after
VMS clusters appeared in 1984. And since the VMS cluster file system
was the only file system available on the platform, suggesting that it
was anything less than fully-usable is rather silly.
Or are you claiming personal experience in this area? If so, please
elaborate: it certainly would seem to differ from my own.
- bill
—
You are currently subscribed to ntfsd as: xxxxx@exmsft.com
To unsubscribe send a blank email to %%email.unsub%%
http://www.polyserve.com/releases/041502.html
Linux, not NT, but a “true” SAN system (i.e., not a metadata server
system). FC switch support, etc.
…dave
(who feels compelled to disclose that he is a PolyServe employee…)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arthur Kreitman
Sent: Monday, April 22, 2002 6:54 PM
To: File Systems Developers
Subject: [ntfsd] Re: How to share storage device on logical block acce
ss level?
iSCSI is just another serial interface. The question was about the
mythical “san” file system
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, April 22, 2002 4:05 PM
To: File Systems Developers
Subject: [ntfsd] Re: How to share storage device on logical block acce
ss level?
iSCSI can be the solution.
----- Original Message -----
From: “Arthur Kreitman”
To: “File Systems Developers”
Sent: Tuesday, April 23, 2002 2:56 AM
Subject: [ntfsd] Re: How to share storage device on logical block acce
ss level?
> I’m also interested in the “solution” to this problem. I’d love
to
> know the name of one commercially successful (success==real market
> share) product that “solves” this problem.
>
> -----Original Message-----
> From: Eric Lee Steadle [mailto:xxxxx@spinnakernet.com]
> Sent: Monday, April 22, 2002 6:32 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: How to share storage device on logical block acce
> ss level?
>
>
> >> First, its a hard problem.
> >Hard? Well, the implementation is not trivial. But it is definitely
> >a
> >solved problem, so the issue is not with uncharted territory.
>
> I’m interested in how this problem was “solved”. Theoretically, or
> practically – I don’t care. Can you provide details, or a link,
> maybe?
>
>
> >No, a good NAS box does something significantly different. In fact,
> >the
> >best NAS box would likely be a box containing an internal cluster
of
> nodes
> >using a clustered file system to serve the data to the rest of the
> >NAS
> world.
>
> Yes, I agree 100% 
>
>
> >While there are certainly limits to the degree to which existing
> distributed
> >lock managers can scale, those limits are significantly higher than
> >the limits to which a ‘good NAS box’ can scale - at least when
> >considered as an alternative for intense server-style cluster
> >applications (the kind that a ‘cluster file system’ is designed to
> >support) as opposed to light access by possibly very large numbers of
> >casual clients (where a NAS-style approach
> is
> >entirely appropriate).
>
> It’s been my experience that the scalability of a NAS box is limited
> by
> the network and processing resources needed by the CIFS protocol. NFS
needs
> very
> little of either to get good performance. CIFS seems to require gobs
of
> both,
> just to piddle along. Distributed Lock Managment seems like it
wouldn’t
> affect
> CIFS performance all that much. I’m interested in your opinion on the
> matter.
>
>
> ERX
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@congruent.com To
> unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntfsd as: xxxxx@congruent.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntfsd as: xxxxx@exmsft.com
To unsubscribe send a blank email to %%email.unsub%%
----- Original Message -----
From: “David Beaver”
To: “File Systems Developers”
Sent: Tuesday, April 23, 2002 12:41 PM
Subject: [ntfsd] Re: How to share storage device on logical block acce ss
level?
> Um, I do have some personal experience with VAXClusters, and we found
> that, for highly available systems (power management control systems),
> VAXClusters would check out for far too long to be usable (on the order
> of minutes, not seconds).
Which I believe is what I said below. Clusters never claimed to be as
highly-available as hardware-coupled redundant systems like Tandem’s and
Stratus’s (that why ftVAX was created - and later dropped because that
turned out to be a niche that was more effort than it was worth to try to
invade, given the existing inhabitants).
This was in 1988; word-of-mouth from the
> company I was at said things got better, but not good enough, later.
Which is also what I said below. Using the configured defaults the
detect/rebuild time dropped to the 5 - 10 second range with the early '90s
V5.x lock manager enhancements (by way of comparison, Sun was still trying
to get its own mechanism down below a minute as recently as a year or two
ago), and if the user was willing to take the hit of upping the ‘heartbeat’
overhead it could be reduced to a couple of seconds: still not fast enough
for some uses, but far faster than any other cluster approach that I’m aware
of can yet accomplish.
So unless you’re contending that clustering itself is not useful (an
assessment that seems inconsistent with the opinion of the market), I’m not
sure what your point is.
- bill
>
> Bottom line in the VAXCluster world was that they would handle
> well-characterized transitions quite well, but did not handle nasty
> stuff at all well (things like pulling power on an HSC50 without
> warning). Perhaps we were asking too much of the clusters at the time.
>
> We ultimately worked around the cluster state transition problems (which
> were, ultimately, DLM state transitions) by failing over from one
> cluster to another, as opposed to from one cluster node to another. Sort
> of negated some of the benfits of the clusters…
>
> …dave
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Bill Todd
> Sent: Monday, April 22, 2002 9:07 PM
> To: File Systems Developers
> Subject: [ntfsd] Re: How to share storage device on logical block acce
> ss level?
>
>
>
> ----- Original Message -----
> From: “Arthur Kreitman”
> To: “File Systems Developers”
> Sent: Monday, April 22, 2002 9:56 PM
> Subject: [ntfsd] Re: How to share storage device on logical block acce
> ss level?
>
>
> > The cluster file system was famous for its distributed lock problems.
>
> > VMS may had been successful, but the cluster file system wasn’t.
>
> Bzzzt! FUD alert!
>
> The cluster file system was indeed famous, but not for any problems.
> The closest anyone came to being able to knock the DLM was because a
> cluster state transition could take up to a minute (in early versions)
> to detect node failure and rebuild the distributed lock database - about
> the same length of time most of the competition (that had clustering at
> all) was still struggling to achieve just a couple of years ago, while
> VMS’s times had been improved to a matter of a few seconds by the early
> '90s.
>
> Of course, these criticisms came from competitors who had no comparable
> facility at all to offer at the time (or for at least a decade later),
> so they could perhaps be forgiven for grasping at any straw they thought
> might not break instantly. They also liked to criticize the
> theoretical scalability of the DLM approach - but, again, VMS has
> supported clusters up to 96 nodes for a very long time and customers
> have successfully run considerably larger ones, while most competitors
> have had to boast about their 2-to-4-node clusters until very recently,
> so their claims sound a bit hollow in this area as well.
>
> Be all that as it may, VMS, and VMS clusters, were indisputably king of
> their not-insignificant hill for a lengthy period both before and after
> VMS clusters appeared in 1984. And since the VMS cluster file system
> was the only file system available on the platform, suggesting that it
> was anything less than fully-usable is rather silly.
>
> Or are you claiming personal experience in this area? If so, please
> elaborate: it certainly would seem to differ from my own.
>
> - bill
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@exmsft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@metrocast.net
> To unsubscribe send a blank email to %%email.unsub%%
>
>