Re: [LSF/MM TOPIC] linux servers as a storage server - what'smissing?

From: Ric Wheeler <rwheeler@redhat.com>
To: "Loke, Chetan" <Chetan.Loke@netscout.com>
Cc: Tom Coughlan <coughlan@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	tasleson@redhat.com, Shyam_Iyer@Dell.com, vgoyal@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] linux servers as a storage server - what'smissing?
Date: Thu, 19 Jan 2012 12:44:10 -0500	[thread overview]
Message-ID: <4F18566A.2060107@redhat.com> (raw)
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B9159135BF@nsmail.netscout.com>

On 01/19/2012 12:32 PM, Loke, Chetan wrote:
>>> True, a single front-end won't see all of those LUNs/devices. So not
>> a
>>> big concern
>>> about the front-end hosts.
>>>
>>> I am thinking of a use-case where folks can use a linux-box to
> manage
>>> 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.
>
>> 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
>> 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