On 01/19/2012 12:32 PM, Loke, Chetan wrote:

quoted

quoted

True, a single front-end won't see all of those LUNs/devices. So not

a

quoted

big concern
about the front-end hosts.

I am thinking of a use-case where folks can use a linux-box to

manage

quoted

quoted

their different storage arrays.
So this linux box with 'libstoragemgmt + app' needs to
manage(scan/create/delete/so on) all those LUNs.

People do have boxes with thousands of luns though&  file systems in
active use.
Both for SAN and NAS volumes.

One of the challenges is what to do when just one LUN (or NFS server)
crashes
and burns.

The FS needs to go read-only(plain&  simple) because you don't know
what's going on.
You can't risk writing data anymore. Let the apps fail. You can make it
happen even today.
It's a simple exercise.

Nope - it needs to be torn down and we need to be able to cleanly unmount it.

Letting an application see and read-only file system when the disk is gone or 
server down is not very useful since you won't get any non-cached data back.

Also, if you have an ability to migrate that mount (same mount point) to another 
server or clone LUN, you want to unmount the source so you can remount the data 
under that same mount point/namespace....

ric

Like others, I have seen/debugged enough weirdness when it comes to
resets/aborts(FYI - 200+ hosts in a cluster).
Because of NDA reasons I can't disclose a whole lot but folks have
fixed/enhanced
scsi stack to make resets/aborts fully robust. And you need folks who
can debug
'apps/FS/block/initiator/wire-protocol/target-side' in one shot. Simple.
So when you say 'crash&  burn' then either or 'all' of the above(minus
the protocol handling) might need fixing.

quoted

You simply cannot "reboot" the server to clean up after one
bad mount when you have thousands of other happy users runs on

thousands/hundreds

quoted

of other mount points :)

Again, can't front-end can go read only and limit the outage w/o
disturbing thousands of users?


Chetan Loke