Re: [linux-lvm] Question about hardware LVM

[Ming Zhang <mingz@ele.uri.edu>]

On Thu, 2006-02-02 at 23:41 -0600, Zac Slade wrote:
> On Thursday 02 February 2006 16:01, Ming Zhang wrote:
> > linux seems can not handle the read_capacity data changed msg from san.
> > so probably u will need to grow it, reconnect from linux, find the
> > changed size, then run fs tools to grow it.
> Neither can many other *nix hosts.  Usually growing is handled at the host 
> level after the LUNs have been increased in size on the SAN.

the point here is whether host can handle it on the fly, or need a
reboot&re-detect.


> 
> > > I have been successfully using LVM on RedHat Linux Server with no
> > > hassle. We are now deploying a $BIGVENDOR expensive FiberChannel SAN.
> > > One of the main features of this SAN is that is able to grow a
> > > filesystem
> Not exactly your terminology is wrong here.  What you mean to say is that one 
> of the main features of a SAN environment is that you can grow LUNs you 
> present to hosts.

think so, unless some $bigname san is file system aware and can do that.
but i do not see any point to do that file system grow from a san point
of view. the sole purpose of san is to export a disk like device.

> 
> > > How does Linux handle this? Do I still have to use LVM? If I still
> > > have to use LVM I do NOT see the point of "hardware base growing".
> > > Simply, create a new LUN in the SAN and I can join to our LVM setup.
> Well to put it bluntly no you don't need LVM just to grow a filesystem from a 
> presented LUN on a SAN.  However if you'd like to use the SAN storage for 
> many filesystems or as a way to offset local storage than you do need volume 
> management.  Enter LVM.

i think this is where to do volume management, or where to do storage
virtualization. if you use linux lvm, it is host based. if u use san
ability, it is array/san based.

> 
> Other considerations in this setup are growing filesystems.  These include 
> JFS, XFS, Reiserfs and some consider ext3 capable for this job (it does have 
> resizing tools check your distros docs).  If you need to shrink filesystems 
> your only real option is Reiserfs.  I will not go into more detail about 
> these filesystems, because you need to evaluate each systems needs and 
> application requirements to determine a filesystem to utilize.  There are 
> plenty of docs on the web with benchmarks and explanations of each.  Do your 
> homework here this is important.
> 
> > > Maybe this is a "Storage 101" questio, but I do not fully understand
> > > expensive SAN "hardware based"  filesystem grow.
> This is Storage 101.  Something you must understand is that LUNs on a SAN 
> might as well be hard disks in a server.  They are block devices that are 
> underneath volume management that is also underneath filesystems.  You will 
> have to maintain the systems on their own.  When a systems needs more space 
> you grow the LUN, then you grow the volume under your volume management 
> software (LVM here) then you grow your filesystem.  Read up on the tools you 
> are using and get a firm understanding of how each one works in the ways you 
> need.

if can grow the lun at san side, a linux lvm might not be needed. so the
layer is file system on top of san exported lun already.

> 
> I hope this sheds some light on what you are getting into.  SANs can be 
> complicated.  Volume management can be a complicated subject.  However, you 
> will have to understand how these fit together in your environment to make 
> good decisions moving forward.

ps, we still misuse LU and LUN. LUN = LU Number. so in most place, we
should use LU instead of LUN. but everybody know this, another storage
101.

ming