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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Ric Wheeler [mailto:rwheeler@xxxxxxxxxx]
> Sent: January 19, 2012 12:44 PM
> To: Loke, Chetan
> Cc: Tom Coughlan; Hannes Reinecke; tasleson@xxxxxxxxxx;
> Shyam_Iyer@xxxxxxxx; vgoyal@xxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx;
> linux-scsi@xxxxxxxxxxxxxxx
> Subject: Re: [LSF/MM TOPIC] linux servers as a storage server -
> what'smissing?
> 
> 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.
> 

Sure, it's just a partial snapshot(aka cached-data) of the file-system.

But writes that have to fetch the non-cached data, will unnecessarily
issue I/O to the fabric. These orphaned I/O's cause more pain in the
cleanup.
And if caching is enabled on the front-side then it's all the more
painful.

We can go one extra step and make FS fail read I/O for non-cached data
too
to avoid more orphan IOs.

Tearing down will happen sometime later. But don't you agree that
something needs
to happen before that? And that something is, read-only, which will
eventually 
propagate to the users(example when you are copying a new file).
Users will then report it to their IT/admins. 
This approach of serving the snap-shot(cached) file-system could serve 
some users for what it's worth. It's better than surprise-removal and
issuing
needless IOs(read - eh race conditions).

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

Won't this be protocol specific.


> ric

Chetan Loke

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux