[linux-lvm] Question about hardware LVM
Ming Zhang
mingz at ele.uri.edu
Fri Feb 3 13:58:16 UTC 2006
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
More information about the linux-lvm
mailing list