> 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
