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 _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
