Re: root filesystem on the NFS
2014-08-28 12:55 GMT-04:00 Grzegorz Powiedziuk gpowiedz...@gmail.com: Hello, If anyone is interested, I am working on a short, general guide for making one of these so I could send it to the group. Someone asked me for a copy of this guide and I've just finished it, so here it is in case more people find it useful: https://drive.google.com/file/d/0B9oswpcRnkaSZWw4ZG9MZFdtZDA/edit?usp=sharing The above is a link to a PDF document. Thanks Gregory Powiedziuk -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Root filesystem error switches to ReadOnly
Fargusson.Alan wrote: Unless this changed in 2.6 the block devices go through VFS, and the blocks get cached by the VFS layer. VFS only comes into play when a filesystem (on a block device) is mounted. If you access a block device directly (not via a path of the mountpoint) then VFS is not involved. The block device is a direct entry to the device driver, you are dealing with blocks and not filesystems at this level. The buffer cache may be used, but this is not filesystem aware, it just caches previously read/written blocks. The point remains that doing a dd of the /dev/dasdn while mounted can lead to a copy that is in a inconsistent state. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Fargusson.Alan wrote: Doing a dd on a device goes through the cache, so in this case the cache can't be the problem. Really? dd is designed to work on block devices that are not mounted, as well as files within a mounted filesystem. I thought the VFS only cached mounted filesystems? If the dd is using something like if=/dev/dasda of=dev/dasdb then I would have thought that the cache would not be used. The cache is only used for mounted filesystems, i.e. files/blocks referenced within the FS via the mountpoint. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Fargusson.Alan wrote: Doing a dd on a device goes through the cache, so in this case the cache can't be the problem. This is not the case. In fact, the page cache is indexed by address spaces and each file as well as each block device has its own address space. Consequently, Linux cannot tell that you're reading/writing the same block on disk via the device node that is already in the cache because it belongs to a file of a mounted filesystem that relies on there. The only safe way of doing an online snapshot of a mounted file system is the dm-snapshot target. Flashcopy and DD don't do the trick. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Rob van der Heij wrote: I expect the problem is using 'dd' for the copying may not get the magic signatures that makes the disk a CDL format, so the driver ends up seeing it as LDL and gets things misaligned. But you should be able to notice that when the new system is booting. This is not the case. Using dd on the entire disk does copy all data in the magic first tracks, and blockdev --rereadpt /dev/target/disk will cause the kernel to reread it on the fly. Just make sure the target is really the same disk layout as the source upfront, because otherwise you'll end up in deep censored because the dasd driver's media detection will see a different disk layout than the partition detection code. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
I expect the problem is using 'dd' for the copying may not get the magic signatures Also 'dd' expects a dasdfmt'd disks or it loses its way. Another approach might be to try dasdfmt'ing the disk before 'dd'. Mike MacIsaac [EMAIL PROTECTED] (845) 433-7061 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
I was not referring to the page cache. The block devices still go through VFS, and the blocks get cached by the VFS layer. I can't say I have read the latest kernel source, so I could be wrong if this changed in 2.6. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Carsten Otte Sent: Friday, August 22, 2008 3:18 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly Fargusson.Alan wrote: Doing a dd on a device goes through the cache, so in this case the cache can't be the problem. This is not the case. In fact, the page cache is indexed by address spaces and each file as well as each block device has its own address space. Consequently, Linux cannot tell that you're reading/writing the same block on disk via the device node that is already in the cache because it belongs to a file of a mounted filesystem that relies on there. The only safe way of doing an online snapshot of a mounted file system is the dm-snapshot target. Flashcopy and DD don't do the trick. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Unless this changed in 2.6 the block devices go through VFS, and the blocks get cached by the VFS layer. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Mark Perry Sent: Thursday, August 21, 2008 11:07 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly Fargusson.Alan wrote: Doing a dd on a device goes through the cache, so in this case the cache can't be the problem. Really? dd is designed to work on block devices that are not mounted, as well as files within a mounted filesystem. I thought the VFS only cached mounted filesystems? If the dd is using something like if=/dev/dasda of=dev/dasdb then I would have thought that the cache would not be used. The cache is only used for mounted filesystems, i.e. files/blocks referenced within the FS via the mountpoint. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
Re: Root filesystem error switches to ReadOnly
van Sleeuwen, Berry wrote: Hello list, For various tests we have created a group of new SLES10 guests. They all are just one 3390-3 volume so they can be cloned vary fast. If you use FLASHCOPY its fast regardless of DASD size. But for some reason these machines sometimes switch the rootdisk, and therefore the entire filesystem, to readonly. I have tried a remount but that didn't work so only a reboot will get the / back in write mode. The reboot itself run without errors. But even that sometimes doesn't solve the error and we have to clone the guest again. We also have a different SLES10 installation and there we don't see any errors there but then we aren't running any load there. I can't find any reason for this, other than what I can find in de guest console log. Any ideas? What can be the cause of this and how can it be fixed? You have a problem in with you root filesystem, so it switches to R/O to give you a chance to fix it, e.g. with fsck. The guest is a SLES10 SP2. I have many SP2 systems, all with ext3 - never any problems at all. [EMAIL PROTECTED]:~ uname -a Linux nlzlx921 2.6.16.60-0.21-default #1 SMP Tue May 6 12:41:02 UTC 2008 s390x s390x s390x GNU/Linux [EMAIL PROTECTED]:~ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/dasda12365444 1682640562644 75% / udev14562064145556 1% /dev The message from the console: 08/08/19 12:23:31 NLZLX921 VMLXES21: EXT3-fs error (device dasda1): ext3_readdir: bad entry in directory #270514: rec_len is 08/08/19 12:23:31 NLZLX921 VMLXES21smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0ŸAborting journal on device 08/08/19 12:23:31 NLZLX921 VMLXES21dasda1.Ÿext3_abort called.ŸEXT3-fs error (d 08/08/19 12:23:31 NLZLX921 VMLXES21: Aug 19 12:23:31 nlzlx921 syslog-ngÃ1092¨: io.c: do_write: write() failed (errno 30), Read-only 08/08/19 12:23:31 NLZLX921 VMLXES21file system When I asked one of our linux specialists he did mention there were a few bugs relating ext3 that have been fixed in RHEL 5.1. Now I have noticed that RHEL 5.1 is on a newer kernel level than the SLES 10 SP2. Could a bug in ext3 by any chance be the problem here? The bug is most likely in your cloning process, perhaps the DASD extents copied and/or used are different. This will only show up when data is used within the bad extent range. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Hello Mark, I meant fast in a way that the / is copied and then changes the hostname and IP address. No other fancy things, just a default environment for our support staff to play around with. The cloning process is loosly based on the cloning scripts from redp4322. The dasd is copied using DASDFMT and dd. Both source (installation machine) and targets are identical, other than the obvious different location of the minidisk extents. The / is a 3338 cylinder minidisk so there it even uses the same minidisk extents but on different DASD volumes. There is one thing I now see, I first regarded as an error due to new disks, but it is still present even when the disks were in use for the guest before. When the copy is done there are some IO errors. 08/08/19 13:41:20 NLZLX920 VMLXES21: end_request: I/O error, dev dasdd, sector 361776Ÿprintk: 630 messages suppressed.ŸBuffer I/O 08/08/19 13:41:20 NLZLX920 VMLXES21error on device dasdd, logical block 45222Ÿlost page write due to I/O error on dasddŸBuffer 08/08/19 13:41:20 NLZLX920 VMLXES21I/O error on device dasdd, logical bl The disk is linked, then DASDFMT and dd. It looks like the IO errors appear within the dd part of the copy process. But how to fix that? Should the guest have some mdisk option to avoid errors? Thanks, Berry. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y
Re: Root filesystem error switches to ReadOnly
van Sleeuwen, Berry wrote: Hello Mark, I meant fast in a way that the / is copied and then changes the hostname and IP address. No other fancy things, just a default environment for our support staff to play around with. The cloning process is loosly based on the cloning scripts from redp4322. The dasd is copied using DASDFMT and dd. Both source (installation machine) and targets are identical, other than the obvious different location of the minidisk extents. The / is a 3338 cylinder minidisk so there it even uses the same minidisk extents but on different DASD volumes. There is one thing I now see, I first regarded as an error due to new disks, but it is still present even when the disks were in use for the guest before. When the copy is done there are some IO errors. FLASHCOPY is still faster ;-) 08/08/19 13:41:20 NLZLX920 VMLXES21: end_request: I/O error, dev dasdd, sector 361776Ÿprintk: 630 messages suppressed.ŸBuffer I/O 08/08/19 13:41:20 NLZLX920 VMLXES21error on device dasdd, logical block 45222Ÿlost page write due to I/O error on dasddŸBuffer 08/08/19 13:41:20 NLZLX920 VMLXES21I/O error on device dasdd, logical bl The disk is linked, then DASDFMT and dd. It looks like the IO errors appear within the dd part of the copy process. But how to fix that? Should the guest have some mdisk option to avoid errors? Thanks, Berry. If doing a dd from linux and the minidisks are identical in size, then one must assume that you have the rights to write to all cylinders. If you issue a vmcp q v da - are source and target the same number of cylinders? I also assume that the source and target are not mounted to Linux while the dd is running? Have you done an fsck on the source volume to ensure it is good? Are you specifying any dd options? Can you do a foreground dd (with -v) and reproduce the error? Is z/VM logging anything - EREP? mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Hello Mark, I'll have to look into the flashcopy process but have not taken the time for it just yet. I guess one thing that would be wrong then is that I copy from the live system. So the source nlzlx920 is being copied from within the nlzlx920. But would that introduce IO errors on the target disks? If anything I'd expect to see errors during boot of the target guest. Either in a filesystemcheck or dmesg afterwards. Much like when you DDR a live VM and get a warmstartdata error when the target is IPLled. Perhaps a rethink of the process is in order. I guess a resque system would be an option. I do like to have a resque machine so I could also use that machine to do the cloning. As for other questions, I also assume I have the rights. No errors on that part. Same amount of cylinders. I have not yet ran the fsck on the source nor did I test it in a failsafe IPL of a new target. I dd with dd bs=4096 if=$sDev of=$tDev no other options. Haven't ran dd during the process by hand, other than a manual test to clone the first machine and to test the steps in the script. No erep or errors within the operator log. There is no error from the VM part. It's only within the linux. Regards, Berry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry Sent: donderdag 21 augustus 2008 12:22 To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly van Sleeuwen, Berry wrote: Hello Mark, I meant fast in a way that the / is copied and then changes the hostname and IP address. No other fancy things, just a default environment for our support staff to play around with. The cloning process is loosly based on the cloning scripts from redp4322. The dasd is copied using DASDFMT and dd. Both source (installation machine) and targets are identical, other than the obvious different location of the minidisk extents. The / is a 3338 cylinder minidisk so there it even uses the same minidisk extents but on different DASD volumes. There is one thing I now see, I first regarded as an error due to new disks, but it is still present even when the disks were in use for the guest before. When the copy is done there are some IO errors. FLASHCOPY is still faster ;-) 08/08/19 13:41:20 NLZLX920 VMLXES21: end_request: I/O error, dev dasdd, sector 361776Ÿprintk: 630 messages suppressed.ŸBuffer I/O 08/08/19 13:41:20 NLZLX920 VMLXES21error on device dasdd, logical block 45222Ÿlost page write due to I/O error on dasddŸBuffer 08/08/19 13:41:20 NLZLX920 VMLXES21I/O error on device dasdd, logical bl The disk is linked, then DASDFMT and dd. It looks like the IO errors appear within the dd part of the copy process. But how to fix that? Should the guest have some mdisk option to avoid errors? Thanks, Berry. If doing a dd from linux and the minidisks are identical in size, then one must assume that you have the rights to write to all cylinders. If you issue a vmcp q v da - are source and target the same number of cylinders? I also assume that the source and target are not mounted to Linux while the dd is running? Have you done an fsck on the source volume to ensure it is good? Are you specifying any dd options? Can you do a foreground dd (with -v) and reproduce the error? Is z/VM logging anything - EREP? mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e
Re: Root filesystem error switches to ReadOnly
van Sleeuwen, Berry wrote: Hello Mark, I'll have to look into the flashcopy process but have not taken the time for it just yet. I guess one thing that would be wrong then is that I copy from the live system. So the source nlzlx920 is being copied from within the nlzlx920. But would that introduce IO errors on the target disks? If anything I'd expect to see errors during boot of the target guest. Either in a filesystemcheck or dmesg afterwards. Much like when you DDR a live VM and get a warmstartdata error when the target is IPLled. Perhaps a rethink of the process is in order. I guess a resque system would be an option. I do like to have a resque machine so I could also use that machine to do the cloning. As for other questions, I also assume I have the rights. No errors on that part. Same amount of cylinders. I have not yet ran the fsck on the source nor did I test it in a failsafe IPL of a new target. I dd with dd bs=4096 if=$sDev of=$tDev no other options. Haven't ran dd during the process by hand, other than a manual test to clone the first machine and to test the steps in the script. No erep or errors within the operator log. There is no error from the VM part. It's only within the linux. Regards, Berry. Never clone a live Linux filesystem. Once the filesystem has been mounted the filesystem is cached in storage (as are updates) and the on disk filesystem is marked 'dirty. Stop the master linux system with a clean shutdown, and copy the disk using flashcopy or ddr if you prefer. This new copy is the master disk to be used for future copies. Reboot the Linux system and run an e2fsck on the new copy to ensure it is good. Then clone as you like ;-) mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
I guess one thing that would be wrong then is that I copy from the live system. I think that's your problem. You're copying from a likely unstable source (the live system might be writing to your volume as you attempt to copy it). Try shutting down the master (live) system with shutdown -h now before you copy from it. The errors you're reporting look like file system structural errors. HTH, --Jim-- -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Mark, Hm, I even didn't think about cache and what it could do to not only files but also to the filesystem itself. And even if I did I'd have guessed it would only mess up a logfile that isn't in use on the target anyway. We would start in a new machine with an empty /var/log/messages and /var/log/warn for example. I think I'll start on a new machine to be used for resque and cloning so that we must run our cloning from a separate machine. Thanks, Berry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry Sent: donderdag 21 augustus 2008 13:27 To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly van Sleeuwen, Berry wrote: Hello Mark, I'll have to look into the flashcopy process but have not taken the time for it just yet. I guess one thing that would be wrong then is that I copy from the live system. So the source nlzlx920 is being copied from within the nlzlx920. But would that introduce IO errors on the target disks? If anything I'd expect to see errors during boot of the target guest. Either in a filesystemcheck or dmesg afterwards. Much like when you DDR a live VM and get a warmstartdata error when the target is IPLled. Perhaps a rethink of the process is in order. I guess a resque system would be an option. I do like to have a resque machine so I could also use that machine to do the cloning. As for other questions, I also assume I have the rights. No errors on that part. Same amount of cylinders. I have not yet ran the fsck on the source nor did I test it in a failsafe IPL of a new target. I dd with dd bs=4096 if=$sDev of=$tDev no other options. Haven't ran dd during the process by hand, other than a manual test to clone the first machine and to test the steps in the script. No erep or errors within the operator log. There is no error from the VM part. It's only within the linux. Regards, Berry. Never clone a live Linux filesystem. Once the filesystem has been mounted the filesystem is cached in storage (as are updates) and the on disk filesystem is marked 'dirty. Stop the master linux system with a clean shutdown, and copy the disk using flashcopy or ddr if you prefer. This new copy is the master disk to be used for future copies. Reboot the Linux system and run an e2fsck on the new copy to ensure it is good. Then clone as you like ;-) mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v
Re: Root filesystem error switches to ReadOnly
Just for a test, try switching the disk references in /etc/fstab to by-path syntax. I'm speculating here, but is it possible that there are some issues with correctly identifying which disk to use for /dev/dasda? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Doing a dd on a device goes through the cache, so in this case the cache can't be the problem. Doing a dd on a live system however will not work. With or without a cache the filesystem can change while you are doing the copy, which would result in a bad root on the new system. I suspect that the errors you are getting are due to the target DASD not being formatted. Did you do a dasdfmt on the target volume? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of van Sleeuwen, Berry Sent: Thursday, August 21, 2008 4:53 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly Mark, Hm, I even didn't think about cache and what it could do to not only files but also to the filesystem itself. And even if I did I'd have guessed it would only mess up a logfile that isn't in use on the target anyway. We would start in a new machine with an empty /var/log/messages and /var/log/warn for example. I think I'll start on a new machine to be used for resque and cloning so that we must run our cloning from a separate machine. Thanks, Berry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry Sent: donderdag 21 augustus 2008 13:27 To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly van Sleeuwen, Berry wrote: Hello Mark, I'll have to look into the flashcopy process but have not taken the time for it just yet. I guess one thing that would be wrong then is that I copy from the live system. So the source nlzlx920 is being copied from within the nlzlx920. But would that introduce IO errors on the target disks? If anything I'd expect to see errors during boot of the target guest. Either in a filesystemcheck or dmesg afterwards. Much like when you DDR a live VM and get a warmstartdata error when the target is IPLled. Perhaps a rethink of the process is in order. I guess a resque system would be an option. I do like to have a resque machine so I could also use that machine to do the cloning. As for other questions, I also assume I have the rights. No errors on that part. Same amount of cylinders. I have not yet ran the fsck on the source nor did I test it in a failsafe IPL of a new target. I dd with dd bs=4096 if=$sDev of=$tDev no other options. Haven't ran dd during the process by hand, other than a manual test to clone the first machine and to test the steps in the script. No erep or errors within the operator log. There is no error from the VM part. It's only within the linux. Regards, Berry. Never clone a live Linux filesystem. Once the filesystem has been mounted the filesystem is cached in storage (as are updates) and the on disk filesystem is marked 'dirty. Stop the master linux system with a clean shutdown, and copy the disk using flashcopy or ddr if you prefer. This new copy is the master disk to be used for future copies. Reboot the Linux system and run an e2fsck on the new copy to ensure it is good. Then clone as you like ;-) mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
van Sleeuwen, Berry wrote: Mark, Hm, I even didn't think about cache and what it could do to not only files but also to the filesystem itself. And even if I did I'd have guessed it would only mess up a logfile that isn't in use on the target anyway. We would start in a new machine with an empty /var/log/messages and /var/log/warn for example. I think I'll start on a new machine to be used for resque and cloning so that we must run our cloning from a separate machine. Thanks, Berry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry Sent: donderdag 21 augustus 2008 13:27 To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem error switches to ReadOnly van Sleeuwen, Berry wrote: Hello Mark, I'll have to look into the flashcopy process but have not taken the time for it just yet. I guess one thing that would be wrong then is that I copy from the live system. So the source nlzlx920 is being copied from within the nlzlx920. But would that introduce IO errors on the target disks? If anything I'd expect to see errors during boot of the target guest. Either in a filesystemcheck or dmesg afterwards. Much like when you DDR a live VM and get a warmstartdata error when the target is IPLled. Perhaps a rethink of the process is in order. I guess a resque system would be an option. I do like to have a resque machine so I could also use that machine to do the cloning. As for other questions, I also assume I have the rights. No errors on that part. Same amount of cylinders. I have not yet ran the fsck on the source nor did I test it in a failsafe IPL of a new target. I dd with dd bs=4096 if=$sDev of=$tDev no other options. Haven't ran dd during the process by hand, other than a manual test to clone the first machine and to test the steps in the script. No erep or errors within the operator log. There is no error from the VM part. It's only within the linux. Regards, Berry. I don't recommend it for normal use, but I have cloned a running Linux system, without mounting its filesystems ro. I did it over a network, and used a procedure like this: 1. Partition target drive 2. mke2fs as needed. 3. mkdir and mount to get the volume structure right. 4. ssh [EMAIL PROTECTED] tar clC /boot / var (whatever) | tar xpC /mnt/dest Now this carries the risk of having some corrupted files - log files, and application data such as your databases and email, unless you shut them down. In my case, that was unimportant. You can safely clone the running system as you did, provided that any mounted relevant filesystems, including /, are mounted ro. Generally, this implies booting to single-user mode. Running fsck after the cloning process will show you it's okay. Never clone a live Linux filesystem. Once the filesystem has been mounted the filesystem is cached in storage (as are updates) and the on disk filesystem is marked 'dirty. Stop the master linux system with a clean shutdown, and copy the disk using flashcopy or ddr if you prefer. This new copy is the master disk to be used for future copies. Reboot the Linux system and run an e2fsck on the new copy to ensure it is good. Then clone as you like ;-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
I expect the problem is using 'dd' for the copying may not get the magic signatures that makes the disk a CDL format, so the driver ends up seeing it as LDL and gets things misaligned. But you should be able to notice that when the new system is booting. Have you considered using DDR or such to copy the disk instead (assuming you may not have the flashcopy feature licenses on the DASD)? -Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
On 8/21/2008 at 5:22 PM, in message [EMAIL PROTECTED], Rob van der Heij [EMAIL PROTECTED] wrote: I expect the problem is using 'dd' for the copying may not get the magic signatures that makes the disk a CDL format, so the driver ends up seeing it as LDL and gets things misaligned. No, that shouldn't happen if they're using dd against the whole volume device node, such as /dev/dasda. If they're doing it against a partition at a time (/dev/dasda1), that should work also, since they'd need to have created the partitions on the target volume to be able to copy them over. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem error switches to ReadOnly
Mark Post wrote: On 8/21/2008 at 5:22 PM, in message [EMAIL PROTECTED], Rob van der Heij [EMAIL PROTECTED] wrote: I expect the problem is using 'dd' for the copying may not get the magic signatures that makes the disk a CDL format, so the driver ends up seeing it as LDL and gets things misaligned. No, that shouldn't happen if they're using dd against the whole volume device node, such as /dev/dasda. If they're doing it against a partition at a time (/dev/dasda1), that should work also, since they'd need to have created the partitions on the target volume to be able to copy them over. Done carefully, one can resize partitions copying with dd. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Mark Post wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. please elaborate ;-) If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. I am sure that view is held by others too, but for many the resource most limited is not storage, it's skilled I.T. support personnel. Any reduction in the amount of administration is usually welcomed with open arms. Others have suggested taking this one level higher to include the z/VM SMAPI to add minidisks from a pool. I think this is a more complete solution. It would allow the administrator to add disks to the z/VM pool in groups rather than ordering them individually. It would allow a much higher level company/dept. storage management. Again I would stress that any such system should be rule based, so as to prevent abuse. It has similarities to a z/OS SMS Group, where multiple z/OS LPARs within the same SYSPLEX can allocate space on-demand across a pool of shared DASD. SMS also has the option to mark pool DASD volumes as available or not, thus allowing an administrator to decide when to allow extra DASD to be made available for allocation. mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/17/2008 at 10:46 PM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: Mark Post wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. please elaborate ;-) It's not instantaneous, just a script that I run via cron to check how much space is being used by the file system(s) I care about. If the available space is too small, it sends me an email, and creates a file that my script to run rsync checks when it kicks off. I would think that if someone wrote a program that used libfam, they could get instantaneous alerts. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Just a comment that such things may be able to be handled by any current monitoring agents you might be running. Nagios? Omegamon? It's usually a good thing to track and implement limit alerts through a central point withing the current monitoring 'infrastructure'... Having said that - no matter what kind of agents are running, I often implement my own check/alert system (simple scripts) for problem machines or ones I'm really keeping a close eye on. So - not suggesting they are mutually exclusive :-) Scott Rohling On Mon, Aug 18, 2008 at 1:22 PM, Mark Post [EMAIL PROTECTED] wrote: On 8/17/2008 at 10:46 PM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: Mark Post wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. please elaborate ;-) It's not instantaneous, just a script that I run via cron to check how much space is being used by the file system(s) I care about. If the available space is too small, it sends me an email, and creates a file that my script to run rsync checks when it kicks off. I would think that if someone wrote a program that used libfam, they could get instantaneous alerts. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/15/2008 at 9:42 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: Is it possible to shrink a LVM fs, not just grow it? In the case of EXT3, the file system must be unmounted to shrink it: umount /path/to/filesystem e2fsck -f /dev/vgname/lvname resize2fs /dev/vgname/lvname desiredsize lvreduce -L desiredsize /dev/vgname/lvname mount /dev/vgname/lvname /path/to/filesystem You'll get a nastygram from lvreduce about data loss. If you are 100% sure you specified the same size as you did for resize2fs (or larger), you'll be OK. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Mark Post wrote: On 8/14/2008 at 8:26 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. Laid out properly, / will never grow. # df -h FilesystemSize Used Avail Use% Mounted on /dev/dasda1 388M 168M 200M 46% / /dev/mapper/vg01-home 97M 4.4M 88M 5% /home /dev/mapper/vg01-opt 74M 21M 50M 30% /opt /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var Of course the amount of space dedicated to each LV will vary according to specific needs. The fundamental concept is the same, and will (hopefully) be the default on SLES11 if things go as I hope. Mark Post Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. Hint to distros: If such a method were available during the installation process then we would not need to make guesstimates of the LV sizes, they could be set small and allowed to grow as packages were installed. If a good idea. then maybe add this to LVM2 so that the whole process was synchronized without the possibility of a FS becoming full (based on rules of course). mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
All IN this long diatribe about root file system no one has mentioned one of the true got ya's - that is the symbolic links of GRUB/LILO. 'Where ever you go - There you are!! ' Richard (Gaz) Gasiorowski Global Solutions Technology Principal Lead Infrastructure Architect 845-773-9243 Work 845-392-7889 Cell [EMAIL PROTECTED] Computer Sciences Corporation Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, USA Registered in Nevada, USA No: C-489-59 - This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. - John Summerfield [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 08/14/2008 11:54 PM Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc Subject Re: Root filesystem Ryan McCain wrote: Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? Read the FHS which can be found at pathname.com. I don't think anyone's managed to put /boot on anything but a bare partition, at least on Intellish hardware. The system boot code has to be able to be found and able to find the kernel initial ramdisk. /lib must be in the root filesystem, as must some others: see the FHS for details. /usr can be ro and shared. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Red Hat is moving from labelling filesystems to using UUIDs. Ugh. I imagine it would be prudent for those cloning systems to include part that generates new UUIDs. Or use a method of addressing storage that DOESN'T tie a logical reference to a specific physical device. You should also consider adding a script to your cloning process to change the default standard volume and group names to names that are unique. This would alleviate the problem of importing a VG for repair. But it also defeats a major purpose of cloning -- to create a large number of *identical* systems. If I change the VG name on every system to keep it safe, I have to document that and I lose a major advantage. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
It's far worse than that. Having / on an LV has _zero_ advantages, since there is never a need to expand the root file system. Having / on an LV introduces additional risk, and will elongate recovery time. That makes the decision very easy. More risk, no benefit, no deal. Put / on an plain partition. It has at least one advantage for us. We are given very limited space to allocate for each guest. This method allows for the rapid installation of either single application/patch or mass deployment/upgrade via ZLM without having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we would then have to shuffle sizes of other filesystems around. Would you agree or am I missing something? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Or just make sure you have good backups. Good and tested backups were the original Knoppix. :) On Thu, Aug 14, 2008 at 10:33 PM, in message [EMAIL PROTECTED], John Summerfield [EMAIL PROTECTED] wrote: Scott Rohling wrote: I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. I think this is one of those topics that is endlessly debatable, so it's best just to list the pros and cons (and not just the cons) and leave it to the implementer to decide why they may or may not want to use LVM for root. DASD. Then - make your system unbootable (put an error in your /etc/fstab or zipl.conf or something) .. and then try and recover it with both an LVM and non-LVM root. These are the kinds of pros and cons you have to weigh yourself.. My Linux experience is principally on Intellish hardware. My favourite rescue disk is Knoppix, preferably the latest but in a pinch, whatever is to hand. It does not understand RH's LVM setup. OTOH RH/Fedora rescue CDs[1] do understand LVM and can mount the system needing rescue. How it would actually handle an incorrect fstab I don't know, but I would fully expect it to get the the point where I could apply a little vim (or sed or echo) and fix it. It's probably complicated to use an alternative standard system to rescue an LVM-rooted system (but maybe not if the alternative doesn't use LVM). I have seen problems discussed where duplicate volume/group names arose, in Fedora. [1] and presumably install media in rescue mode. In a mainframe environment I'd want to do as I did on OS/2, have a small utility/rescue system on hand for just such emergencies. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
We have something like this on z/OS Unix. It does not work as well as you might think. All it does is push the space problems out to the volume level. We end up having to un-mount the filesystem, move it to a new volume, and re-mount it. I would vote to not do this on Linux. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Mark Perry Sent: Friday, August 15, 2008 12:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Mark Post wrote: On 8/14/2008 at 8:26 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. Laid out properly, / will never grow. # df -h FilesystemSize Used Avail Use% Mounted on /dev/dasda1 388M 168M 200M 46% / /dev/mapper/vg01-home 97M 4.4M 88M 5% /home /dev/mapper/vg01-opt 74M 21M 50M 30% /opt /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var Of course the amount of space dedicated to each LV will vary according to specific needs. The fundamental concept is the same, and will (hopefully) be the default on SLES11 if things go as I hope. Mark Post Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. Hint to distros: If such a method were available during the installation process then we would not need to make guesstimates of the LV sizes, they could be set small and allowed to grow as packages were installed. If a good idea. then maybe add this to LVM2 so that the whole process was synchronized without the possibility of a FS becoming full (based on rules of course). mark -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
Re: Root filesystem
On 8/15/2008 at 7:29 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: -snip- It has at least one advantage for us. We are given very limited space to allocate for each guest. This method allows for the rapid installation of either single application/patch or mass deployment/upgrade via ZLM without having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we would then have to shuffle sizes of other filesystems around. Would you agree or am I missing something? That's not an advantage, it's a workaround for bad management decisions. Coming to Novell from a company where our z/VM systems were overly resource constrained, I completely understand your situation. The best you can do is do what you have to do and document for management the potential risks and business impact of their decision to not provide the necessary hardware resources to do things the right way (understanding there is debate about what right is). Then, if Murphy strikes, and people are asking why you did things that way, you have covered yourself and your team as much as you can. If I were put (back) in your position, I wouild try to do some research ahead of time to figure out what set of standardized system templates I might be creating, and adjust the file system layout I favor to support those. Just about everyone I've spoken to has done just that, whether / is on an LV or not, and gotten those templates approved by security, etc. You don't want every system you create to be a one off situation. That won't be to your advantage in any way. In general, you shouldn't be having to install lots of new packages, just maintenance, for the life of a particular guest. If you are, then something in your ogranizational or development processes are broken. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
If you have disk sitting around that you could add to the VG then why not add them to the VG when you create it, and make the filesystems large enough that they don't need to grow? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
That was my first thought too... BUT - I can see how it could be useful to have free space in a VG and then assign it where it might be needed as it's needed within the VG. (Leave 1GB of the VG unassigned, and let the script assign it on an 'emergency' basis to the LV that is running low). More interesting is the notion of getting VM to assign the disk and then have it automatically added to the VG. (Think application data). If the method involves just have a bunch of VM minidisks already assigned to the guest, ready to be added - then I agree - why not just assign them now. Scott Rohling On Fri, Aug 15, 2008 at 10:20 AM, Fargusson.Alan [EMAIL PROTECTED]wrote: If you have disk sitting around that you could add to the VG then why not add them to the VG when you create it, and make the filesystems large enough that they don't need to grow? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Thanks for the info. I'm going to discuss this further with management. On Fri, Aug 15, 2008 at 11:01 AM, in message [EMAIL PROTECTED], Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 7:29 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: -snip- It has at least one advantage for us. We are given very limited space to allocate for each guest. This method allows for the rapid installation of either single application/patch or mass deployment/upgrade via ZLM without having to guesstimate ahead of time that /opt will be 1.1 gig, /tmp will be 500 meg, etc. Using my example, if we need to grow /opt to 1.5 gig, we would then have to shuffle sizes of other filesystems around. Would you agree or am I missing something? That's not an advantage, it's a workaround for bad management decisions. Coming to Novell from a company where our z/VM systems were overly resource constrained, I completely understand your situation. The best you can do is do what you have to do and document for management the potential risks and business impact of their decision to not provide the necessary hardware resources to do things the right way (understanding there is debate about what right is). Then, if Murphy strikes, and people are asking why you did things that way, you have covered yourself and your team as much as you can. If I were put (back) in your position, I wouild try to do some research ahead of time to figure out what set of standardized system templates I might be creating, and adjust the file system layout I favor to support those. Just about everyone I've spoken to has done just that, whether / is on an LV or not, and gotten those templates approved by security, etc. You don't want every system you create to be a one off situation. That won't be to your advantage in any way. In general, you shouldn't be having to install lots of new packages, just maintenance, for the life of a particular guest. If you are, then something in your ogranizational or development processes are broken. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
This would be an obvious use of Jack Wohr's pigiron tool (although bearing the cost of a JVM might be more mass than is really supportable). VM SMAPI provides functions to add minidisks to a guest, and the automation to access the disk, put it online and do the pvcreate, etc would be fairly straightforward once you have the ability to interact with the hypervisor management infrastructure. The filesystem monitor interface might be the only moderately complex part. Wrt to why, if you have a chargeback environment, preallocating space you're not using makes users whiny. Create on use makes that discussion less complex (they still whine, but it's clear what happened and why). -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Is it possible to shrink a LVM fs, not just grow it? On Fri, Aug 15, 2008 at 11:04 AM, in message [EMAIL PROTECTED], Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I have problems with this kind of thing on z/OS Unix. Our /tmp filesystem on z/OS is nearly a full volume with usage around 2% because DB2 was configured to write a log file to /tmp, and someone ran a load test that cause DB2 to write 1.2G of log data. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:37 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem That was my first thought too... BUT - I can see how it could be useful to have free space in a VG and then assign it where it might be needed as it's needed within the VG. (Leave 1GB of the VG unassigned, and let the script assign it on an 'emergency' basis to the LV that is running low). More interesting is the notion of getting VM to assign the disk and then have it automatically added to the VG. (Think application data). If the method involves just have a bunch of VM minidisks already assigned to the guest, ready to be added - then I agree - why not just assign them now. Scott Rohling On Fri, Aug 15, 2008 at 10:20 AM, Fargusson.Alan [EMAIL PROTECTED]wrote: If you have disk sitting around that you could add to the VG then why not add them to the VG when you create it, and make the filesystems large enough that they don't need to grow? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Friday, August 15, 2008 9:11 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem If you're talking about a VG that has free space and a script smart enough to add the free space and do the resize, etc -- then it sounds nifty and not too hard. If you're talking about getting VM to give you another minidisk, which you then add to the VG and then add space to the LV -- that's a magnitude more complicated (but certainly doable with things like REXECD on VM, vmcp to link the disks, etc). But still - that would be nifty too :-) Interesting idea... Scott Rohling On Fri, Aug 15, 2008 at 10:04 AM, Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
This seems odd to me. If I were the user getting charged by the amount of space I would not want it to grow without being told I was going to be charged more. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem This would be an obvious use of Jack Wohr's pigiron tool (although bearing the cost of a JVM might be more mass than is really supportable). VM SMAPI provides functions to add minidisks to a guest, and the automation to access the disk, put it online and do the pvcreate, etc would be fairly straightforward once you have the ability to interact with the hypervisor management infrastructure. The filesystem monitor interface might be the only moderately complex part. Wrt to why, if you have a chargeback environment, preallocating space you're not using makes users whiny. Create on use makes that discussion less complex (they still whine, but it's clear what happened and why). -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
It depends on the filesystem. Some can shrink and some can't. Also some can shrink only if there are no used blocks in the area that is going to be removed. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Is it possible to shrink a LVM fs, not just grow it? On Fri, Aug 15, 2008 at 11:04 AM, in message [EMAIL PROTECTED], Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
We are mainly an EXT3 shop. I know z/VM can grow an LVMd EXT3 fs, just not sure if it has the ability to shrink it. On Fri, Aug 15, 2008 at 12:07 PM, in message [EMAIL PROTECTED], Fargusson.Alan [EMAIL PROTECTED] wrote: It depends on the filesystem. Some can shrink and some can't. Also some can shrink only if there are no used blocks in the area that is going to be removed. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Is it possible to shrink a LVM fs, not just grow it? On Fri, Aug 15, 2008 at 11:04 AM, in message [EMAIL PROTECTED], Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
See lvreduce .. also vgreduce (but you can only remove unused physical volumes which ain't always easy). If you do a 'man lvreduce' it will caution you that you need to resize the filesystem before you resize the LV.. pay attention to that :-) Scott Rohling On Fri, Aug 15, 2008 at 11:24 AM, Ryan McCain [EMAIL PROTECTED]wrote: We are mainly an EXT3 shop. I know z/VM can grow an LVMd EXT3 fs, just not sure if it has the ability to shrink it. On Fri, Aug 15, 2008 at 12:07 PM, in message [EMAIL PROTECTED], Fargusson.Alan [EMAIL PROTECTED] wrote: It depends on the filesystem. Some can shrink and some can't. Also some can shrink only if there are no used blocks in the area that is going to be removed. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Friday, August 15, 2008 9:43 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Is it possible to shrink a LVM fs, not just grow it? On Fri, Aug 15, 2008 at 11:04 AM, in message [EMAIL PROTECTED], Mark Post [EMAIL PROTECTED] wrote: On 8/15/2008 at 12:58 AM, in message [EMAIL PROTECTED], Mark Perry [EMAIL PROTECTED] wrote: -snip- Is there a way to trigger a script when a filesystem (FS) hits a certain percentage full? (90%?) Of course. I have such a thing set up on my Slack/390 development systems so that I know when to temporarily suspend rsynching from my upstream source at slackware.com. If so, then one could develop a method to automatically issue the required lvresize and ext2online commands to keep the FS within a certain percentage range (70-90%?). Of course rules could be developed to make this more sophisticated: which FS are controlled, what % range per FS, limits of VG % free etc. You're certainly willing to do that to yourself. I would not want to do it, nor make that available to others. That sort of thing is very, very, complicated, and I would want a human looking at that and making decisions, not software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Could I put the root filesystem outside of LVM and just not /boot? Isn't that the real issue? Thanks.. On Wed, Aug 13, 2008 at 7:45 PM, in message [EMAIL PROTECTED], dave [EMAIL PROTECTED] wrote: Hi, John. I didn't say that LVMs are inherently risky or unreliable. By all means build and use LVMs to hold your application data and code. Just don't put the root Linux file system (the one Linux needs to boot from...) in an LVM. It makes recovery of a sick penguin in a z/VM environment must easier. - Original Message - From: John Summerfield [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Date: Thu, 14 Aug 2008 09:32:04 +0800 dave wrote: Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this Oh. Why does Red Hat default to using LVM? If LVM is so unreliable that it's risky to use it for one's root filesystem (which, in principle can easily be recovered if needs be), then how much more risky is it to use LVM for one's most valuables? chortle -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Is there a list of pro's and con's somewhere? On Wed, Aug 13, 2008 at 11:47 PM, in message [EMAIL PROTECTED], Scott Rohling [EMAIL PROTECTED] wrote: I didn't say that LVMs are inherently risky or unreliable. By all means build and use LVMs to hold your application data and code. Just don't put the root Linux file system (the one Linux needs to boot from...) in an LVM. It makes recovery of a sick penguin in a z/VM environment must easier. And expansion of a root filesystem much harder. As pointed out, RedHat defaults to an LVM root - so it's harder to brush it aside as just a bad idea. I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. I think this is one of those topics that is endlessly debatable, so it's best just to list the pros and cons (and not just the cons) and leave it to the implementer to decide why they may or may not want to use LVM for root. I say there are good reasons to do it, so it should be something that is carefully considered. My best advice to the original appender is to try it.. and understand first-hand the differences. Fill up root and see if it's easier to add DASD to an LVM or move the whole fileystem to another DASD. Then - make your system unbootable (put an error in your /etc/fstab or zipl.conf or something) .. and then try and recover it with both an LVM and non-LVM root. These are the kinds of pros and cons you have to weigh yourself.. Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Leave it outside LVM. It's one less thing you'll get paged about at 3 AM on Sunday. Use LVM for everything else, but leave / on a basic plain old partition. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. In the x86 world, we've been putting / in LVM for years and have never had a problem. Is there something specific about z/VM that doesn't play well with / in LVM? I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? Thanks, Ryan On Thu, Aug 14, 2008 at 10:15 AM, in message [EMAIL PROTECTED], Robert J Brenneman [EMAIL PROTECTED] wrote: Leave it outside LVM. It's one less thing you'll get paged about at 3 AM on Sunday. Use LVM for everything else, but leave / on a basic plain old partition. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
It is not the case the /boot is the issue. As soon as the kernel starts it mounts the root. If mounting the root fails then the kernel gives up, and you have to recover the root filesystem. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 7:21 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Could I put the root filesystem outside of LVM and just not /boot? Isn't that the real issue? Thanks.. On Wed, Aug 13, 2008 at 7:45 PM, in message [EMAIL PROTECTED], dave [EMAIL PROTECTED] wrote: Hi, John. I didn't say that LVMs are inherently risky or unreliable. By all means build and use LVMs to hold your application data and code. Just don't put the root Linux file system (the one Linux needs to boot from...) in an LVM. It makes recovery of a sick penguin in a z/VM environment must easier. - Original Message - From: John Summerfield [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Date: Thu, 14 Aug 2008 09:32:04 +0800 dave wrote: Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this Oh. Why does Red Hat default to using LVM? If LVM is so unreliable that it's risky to use it for one's root filesystem (which, in principle can easily be recovered if needs be), then how much more risky is it to use LVM for one's most valuables? chortle -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
There have been several times when people have posted to this list asking for help recovering when a LVM containing the root filesystem has gone bad. It may be that when using VM you have more of a chance of messing up. Why would you need to expand the root FS? You should be splitting out /opt, /tmp, and /usr, which I think would keep any files that are going to grow off of the root. If there is some other directory that has files that are going to grow I would separate it onto another disk as well. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 8:27 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. In the x86 world, we've been putting / in LVM for years and have never had a problem. Is there something specific about z/VM that doesn't play well with / in LVM? I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? Thanks, Ryan On Thu, Aug 14, 2008 at 10:15 AM, in message [EMAIL PROTECTED], Robert J Brenneman [EMAIL PROTECTED] wrote: Leave it outside LVM. It's one less thing you'll get paged about at 3 AM on Sunday. Use LVM for everything else, but leave / on a basic plain old partition. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On Thu, Aug 14, 2008 at 5:36 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: There have been several times when people have posted to this list asking for help recovering when a LVM containing the root filesystem has gone bad. It may be that when using VM you have more of a chance of messing up. It's probably that you have different options on VM to repair if it breaks. It turns out to be very hard to do a complete virtualization of the walk over to the local console of the server and insert the CD and hack it. So we try to come up with an approach that provides the same function but with some different tools. While doing that, it makes sense to see whether the big road blocks actually need to be there. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On Thu, Aug 14, 2008 at 5:30 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: It is not the case the /boot is the issue. As soon as the kernel starts it mounts the root. If mounting the root fails then the kernel gives up, and you have to recover the root filesystem. The motivation to split off /boot stems from ancient PC hardware etc that required the boot stuff to be on low cylinder numbers. So you made a /boot partition that resides at the start of the disk. This has no relevance with Linux on z/VM (unless you want to do something like a 2nd IPL volume for Linux to back-out a kernel update, but that takes a bit more to do it right). -Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
LVM is no less reliable on z/VM than it is on any other platform - but I wouldn't use LVM for my / filesystem on i386 either. In my experience, when you lose a PV and thus the entire VG with it - it's easier to recover the system when it still boots due to having / on a basic partition. If you're using LVM and a PV drops for whatever reason - most likely a finger check by someone, somewhere - you'll have to boot the system with recovery media, mount the volumes, chroot in, then fix it. You can't just fix it in place. In distributed systems this might be less of a problem, since everyone mostly uses the onboard SCSI disks, and thus theres no one else but you that you have to worry about. In Z, all disk is out in a network of some type ( FICON or SAN ) and thus more people are involved, and some shops ( like mine ) have multiple admins doing storage management in a shared everything environment. That's why I'm a bit shy about LVM for / -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. I guess my first question is why is / expanding at all? If you're getting a need for expanding root filesystems, something else is wrong. The case for the other filesystems is fine; I'd agree on putting them in LVM in a second. I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? It's not a good idea because: 1) It encourages poor management of file placement by vendors and users. 2) It complicates recovery of a failed system by requiring you to restore more than one disk to ensure consistent state. 3) It complicates cloning and replication of system images in that if you use a template VG structure, it is difficult to be able to import a VG for repair in another system if all the VG names are the same (ie, you can't easily fix it if all your VGs are called system_vg, including the one in your recovery system). 4) It complicates getting a failed system back on the network so that you can fix whatever else happened. You don't see a lot of these problems in the Intel space because the network is less critical to Intel systems, and you can't really share access to resources between machines easily. As you migrate your Intel systems to virtual machines, the same problems start cropping up there too. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I was thinking of things like accidentally re-labeling a disk, or changing the wrong user entry. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Rob van der Heij Sent: Thursday, August 14, 2008 8:42 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem On Thu, Aug 14, 2008 at 5:36 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: There have been several times when people have posted to this list asking for help recovering when a LVM containing the root filesystem has gone bad. It may be that when using VM you have more of a chance of messing up. It's probably that you have different options on VM to repair if it breaks. It turns out to be very hard to do a complete virtualization of the walk over to the local console of the server and insert the CD and hack it. So we try to come up with an approach that provides the same function but with some different tools. While doing that, it makes sense to see whether the big road blocks actually need to be there. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
You _don't_ have to guess ... there is not much which can grow, if you outsource /opt and /var. We are running our / with 2 GB and there is more than enough space left. And if you need another service *MYSQL or similiar* perhaps it is usefull to check if another zLinux guest is necessary ;) Christian Langer Ryan McCain schrieb am 14.08.2008 17:26: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. In the x86 world, we've been putting / in LVM for years and have never had a problem. Is there something specific about z/VM that doesn't play well with / in LVM? I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? Thanks, Ryan On Thu, Aug 14, 2008 at 10:15 AM, in message [EMAIL PROTECTED], Robert J Brenneman [EMAIL PROTECTED] wrote: Leave it outside LVM. It's one less thing you'll get paged about at 3 AM on Sunday. Use LVM for everything else, but leave / on a basic plain old partition. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- |Zentrum für Informationsverarbeitung | und Informationstechnik |Haus I Raum 339 |An der Kueppe 2 |53225 Bonn |Mail: [EMAIL PROTECTED] |Tel: 0228 99680 5199 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 signature.asc Description: OpenPGP digital signature
Re: Root filesystem
Valid points. I guess if one has solid backups it is more of a moot point, correct? In the z/VM world, is it common for / to get wasted any more than in the x86 world? On Thu, Aug 14, 2008 at 10:41 AM, in message [EMAIL PROTECTED], Rob van der Heij [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 5:36 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: There have been several times when people have posted to this list asking for help recovering when a LVM containing the root filesystem has gone bad. It may be that when using VM you have more of a chance of messing up. It's probably that you have different options on VM to repair if it breaks. It turns out to be very hard to do a complete virtualization of the walk over to the local console of the server and insert the CD and hack it. So we try to come up with an approach that provides the same function but with some different tools. While doing that, it makes sense to see whether the big road blocks actually need to be there. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I think it is that the root is more critical. If /usr goes bad you can still boot up. If root goes bad you can't boot up. If you can boot up it is easier to fix things. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 8:55 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Valid points. I guess if one has solid backups it is more of a moot point, correct? In the z/VM world, is it common for / to get wasted any more than in the x86 world? On Thu, Aug 14, 2008 at 10:41 AM, in message [EMAIL PROTECTED], Rob van der Heij [EMAIL PROTECTED] wrote: On Thu, Aug 14, 2008 at 5:36 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: There have been several times when people have posted to this list asking for help recovering when a LVM containing the root filesystem has gone bad. It may be that when using VM you have more of a chance of messing up. It's probably that you have different options on VM to repair if it breaks. It turns out to be very hard to do a complete virtualization of the walk over to the local console of the server and insert the CD and hack it. So we try to come up with an approach that provides the same function but with some different tools. While doing that, it makes sense to see whether the big road blocks actually need to be there. Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Ryan McCain wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. In the x86 world, we've been putting / in LVM for years and have never had a problem. Is there something specific about z/VM that doesn't play well with / in LVM? I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? Because, unlike x86 boxes, you can't just drop in a CD and recover the LVM. It's much easier to fix things when you can get the initial system up without many headaches. I look at it as I was taught a few years ago for LPI certification. It talked about the bad old days when disks were small and you needed to stretch the file systems across may of them. You would have a basic local system with /, /root, /boot, /etc, and /sbin available locally and could have the rest available through NFS or other shared disk interfaces. I look on the z systems the same way; put at least those in a static partition and the rest could go into LVM. Of course, you can extend any part of the filesystem with mounts in LVM space later. That way I have at least enough to figure out and fix the LVM if it hiccups. Kim -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 begin:vcard fn:Kim Goldenberg n:Goldenberg;Kim org:State of New Jersey;Office of Information Technology (OIT) adr:200 Riverview Plaza;;PO Box 212;Trenton;NJ;08625-0212;USA email;internet:[EMAIL PROTECTED] title:Systems Programmer I tel;work:609-777-3722 tel;fax:609-777-3939 x-mozilla-html:FALSE url:http://www.state.nj.us version:2.1 end:vcard
Re: Root filesystem
[EMAIL PROTECTED] wrote: Is there a list of pro's and con's somewhere? There may be some list out on the web - but to me there are just a few: Pro: - Extending root can be done without restarting the guest, by adding a volume to the VG and doing an ext2online. Same reason for putting app/data into an LVM.. Con: - Recovery can be trickier if you're used to only have a single root partition. There also seems to be a faction which contends that if you separate your 'growing' directories (/usr, /var, /tmp, etc) then root should not grow or need to be extended. Make those directories LVM's and mount them over the appropriate dir. This can work well and can be done whether you use an LVM for root or not. My point of view is that there is only one reason to put / in an LVM: easier expansion if needed. Some of those calls others have referred to in the middle of the night can happen because root fills up.. and being able to dynamically add space without bringing down Linux can be an easy fix until the cause of the unexpected file writing can be determined. Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. On Thu, Aug 14, 2008 at 10:49 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. I guess my first question is why is / expanding at all? If you're getting a need for expanding root filesystems, something else is wrong. The case for the other filesystems is fine; I'd agree on putting them in LVM in a second. I keep reading where it's not a good idea to put / in LVM, but can you (or someone else) define actually why it's not a good idea? It's not a good idea because: 1) It encourages poor management of file placement by vendors and users. 2) It complicates recovery of a failed system by requiring you to restore more than one disk to ensure consistent state. 3) It complicates cloning and replication of system images in that if you use a template VG structure, it is difficult to be able to import a VG for repair in another system if all the VG names are the same (ie, you can't easily fix it if all your VGs are called system_vg, including the one in your recovery system). 4) It complicates getting a failed system back on the network so that you can fix whatever else happened. You don't see a lot of these problems in the Intel space because the network is less critical to Intel systems, and you can't really share access to resources between machines easily. As you migrate your Intel systems to virtual machines, the same problems start cropping up there too. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
My point of view is that there is only one reason to put / in an LVM: easier expansion if needed. Some of those calls others have referred to in the middle of the night can happen because root fills up.. and being able to dynamically add space without bringing down Linux can be an easy fix until the cause of the unexpected file writing can be determined. That is how I'm looking at it. Saying that, I'm not very familiar with the inner workings of z/VM. All of our 100+ x86 Linux servers have / in LVM and over the past year we've had to completley rebuild a server maybe once. I guess I don't expect the 3am calls like everyone else because I've never had them before w/ Linux on x86. On Thu, Aug 14, 2008 at 11:01 AM, in message [EMAIL PROTECTED], Scott Rohling [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Is there a list of pro's and con's somewhere? There may be some list out on the web - but to me there are just a few: Pro: - Extending root can be done without restarting the guest, by adding a volume to the VG and doing an ext2online. Same reason for putting app/data into an LVM.. Con: - Recovery can be trickier if you're used to only have a single root partition. There also seems to be a faction which contends that if you separate your 'growing' directories (/usr, /var, /tmp, etc) then root should not grow or need to be extended. Make those directories LVM's and mount them over the appropriate dir. This can work well and can be done whether you use an LVM for root or not. My point of view is that there is only one reason to put / in an LVM: easier expansion if needed. Some of those calls others have referred to in the middle of the night can happen because root fills up.. and being able to dynamically add space without bringing down Linux can be an easy fix until the cause of the unexpected file writing can be determined. Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? On Thu, Aug 14, 2008 at 11:15 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Others can chime in - but the biggest reason I find for an LVM 'going bad' - is that one of the disks that make up the LVM isn't online. Someone forgot to update zipl.conf or modprobe.conf and didn't do a zipl or mkinitrd when they added the disk - so next time it boots - it's missing one of the LVM disks. Or - someone really hosed up something when they did the expansion - usually you know about that right away! Or - someone didn't update the VM directory to indicate the disk is now owned by this guest.. rarer but I've seen it happen. Other than the virtual nature of the disks and that they aren't hardwired to the server, I don't see any reason to handle them differently than in the x86 world. They're no more dangerous on z/VM than they are anywhere else..Any of the reasons an LVM might 'go bad' on x86 applies to z/VM as well (and vice-a-versa).. Admittedly - it's probably easier to yank a disk away from a guest than it is to yank a hard drive out of an x86 server :-) Scott Rohling On Thu, Aug 14, 2008 at 10:13 AM, Ryan McCain [EMAIL PROTECTED]wrote: My point of view is that there is only one reason to put / in an LVM: easier expansion if needed. Some of those calls others have referred to in the middle of the night can happen because root fills up.. and being able to dynamically add space without bringing down Linux can be an easy fix until the cause of the unexpected file writing can be determined. That is how I'm looking at it. Saying that, I'm not very familiar with the inner workings of z/VM. All of our 100+ x86 Linux servers have / in LVM and over the past year we've had to completley rebuild a server maybe once. I guess I don't expect the 3am calls like everyone else because I've never had them before w/ Linux on x86. On Thu, Aug 14, 2008 at 11:01 AM, in message [EMAIL PROTECTED], Scott Rohling [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Is there a list of pro's and con's somewhere? There may be some list out on the web - but to me there are just a few: Pro: - Extending root can be done without restarting the guest, by adding a volume to the VG and doing an ext2online. Same reason for putting app/data into an LVM.. Con: - Recovery can be trickier if you're used to only have a single root partition. There also seems to be a faction which contends that if you separate your 'growing' directories (/usr, /var, /tmp, etc) then root should not grow or need to be extended. Make those directories LVM's and mount them over the appropriate dir. This can work well and can be done whether you use an LVM for root or not. My point of view is that there is only one reason to put / in an LVM: easier expansion if needed. Some of those calls others have referred to in the middle of the night can happen because root fills up.. and being able to dynamically add space without bringing down Linux can be an easy fix until the cause of the unexpected file writing can be determined. Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I usually split out /opt /usr /home /var /tmp and /srv in a single VG. that makes it easy to move space around between them. /lib /boot /bin /sbin and /etc I leave in / since they all need to be there for it to be bootable. Split this way - the / should not really grow by more than 10%, if at all, due to applying security fixes. -- Jay Brenneman -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
The answer is: it depends. I usually try to put /usr, /opt, /var, and /tmp on separate filesystems. One big HOWEVER is that I know that my users don't use much space in their home directories. I would separate /home out if I didn't know this for sure. We only have 3390-3s, so I start with one volume per filesystem, except /tmp. Since /tmp can be much smaller I use create a minidisk of around 300 cylinders. We are not doing much with Linux on Z right now, so /tmp may need to be larger if you are doing a lot of compiles, or anything that creates large temporary files. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 9:24 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? On Thu, Aug 14, 2008 at 11:15 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
This is sort of going a different direction - but I often divide the root LVM (when I use one) into logical volumes that are mounted as / , /usr, /var, /opt, /tmp, etc. (VG root LV usr mount /dev/root/usr /usr , etc) That might seem at crosspurposes to what's been discussed, but it keeps the 'OS' stuff in one VG as much as possible, and also allows for some management of the sizes of those system dirs. Using a bit more of /usr than anticipated? - add some free space from the root VG (or add another DASD to it) and dynamically increase /usr. I prefer having a single root LVM but with logical volumes that map to directories which I can expand individually as needed. I prefer as few VG's in use as possible. One for system - one for apps - maybe another for data, depending on the situation.. Even if you don't mount root as an LVM itself - you can still manage all the system dirs (/usr, /var, etc) under a single VG with seperate LVs. Scott Rohling On Thu, Aug 14, 2008 at 10:45 AM, Fargusson.Alan [EMAIL PROTECTED]wrote: The answer is: it depends. I usually try to put /usr, /opt, /var, and /tmp on separate filesystems. One big HOWEVER is that I know that my users don't use much space in their home directories. I would separate /home out if I didn't know this for sure. We only have 3390-3s, so I start with one volume per filesystem, except /tmp. Since /tmp can be much smaller I use create a minidisk of around 300 cylinders. We are not doing much with Linux on Z right now, so /tmp may need to be larger if you are doing a lot of compiles, or anything that creates large temporary files. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 9:24 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? On Thu, Aug 14, 2008 at 11:15 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Thanks to everyone for their input. This makes much more sense now. Ryan On Thu, Aug 14, 2008 at 11:45 AM, in message [EMAIL PROTECTED], Fargusson.Alan [EMAIL PROTECTED] wrote: The answer is: it depends. I usually try to put /usr, /opt, /var, and /tmp on separate filesystems. One big HOWEVER is that I know that my users don't use much space in their home directories. I would separate /home out if I didn't know this for sure. We only have 3390-3s, so I start with one volume per filesystem, except /tmp. Since /tmp can be much smaller I use create a minidisk of around 300 cylinders. We are not doing much with Linux on Z right now, so /tmp may need to be larger if you are doing a lot of compiles, or anything that creates large temporary files. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 9:24 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? On Thu, Aug 14, 2008 at 11:15 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I like what you are doing. I would put the root on one volume, and put the rest in a volume group. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Scott Rohling Sent: Thursday, August 14, 2008 9:58 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem This is sort of going a different direction - but I often divide the root LVM (when I use one) into logical volumes that are mounted as / , /usr, /var, /opt, /tmp, etc. (VG root LV usr mount /dev/root/usr /usr , etc) That might seem at crosspurposes to what's been discussed, but it keeps the 'OS' stuff in one VG as much as possible, and also allows for some management of the sizes of those system dirs. Using a bit more of /usr than anticipated? - add some free space from the root VG (or add another DASD to it) and dynamically increase /usr. I prefer having a single root LVM but with logical volumes that map to directories which I can expand individually as needed. I prefer as few VG's in use as possible. One for system - one for apps - maybe another for data, depending on the situation.. Even if you don't mount root as an LVM itself - you can still manage all the system dirs (/usr, /var, etc) under a single VG with seperate LVs. Scott Rohling On Thu, Aug 14, 2008 at 10:45 AM, Fargusson.Alan [EMAIL PROTECTED]wrote: The answer is: it depends. I usually try to put /usr, /opt, /var, and /tmp on separate filesystems. One big HOWEVER is that I know that my users don't use much space in their home directories. I would separate /home out if I didn't know this for sure. We only have 3390-3s, so I start with one volume per filesystem, except /tmp. Since /tmp can be much smaller I use create a minidisk of around 300 cylinders. We are not doing much with Linux on Z right now, so /tmp may need to be larger if you are doing a lot of compiles, or anything that creates large temporary files. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Ryan McCain Sent: Thursday, August 14, 2008 9:24 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? On Thu, Aug 14, 2008 at 11:15 AM, in message [EMAIL PROTECTED], David Boyes [EMAIL PROTECTED] wrote: The main reason is we have a limited about of disk to allocate and we will have a hard time saying X gigs go to /opt, Y gigs will be needed for /home, etc. Then put those secondary directories into LVMs and mount them at boot time in /etc/fstab -- no problem there. It's really just / that we're worrying about here. For a manageable system in a large configuration, / is (and should be) small and rarely changed -- all it has to do is provide mount points for other filesystems, either in LVM, network, FCP, etc. In most cases, / contains enough to get the system up and on the network to the point where you can work with it. Once you can do that, you can do anything else you want to do fairly easily. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/13/2008 at 6:32 PM, in message [EMAIL PROTECTED], John Summerfield [EMAIL PROTECTED] wrote: -snip- Oh. Why does Red Hat default to using LVM? Since I work in NTS now, I can engage in some educated speculation, but speculation nonetheless: - The people who made this decision were never responsible for supporting hundreds of production servers in an enterprise - It eliminated a lot of nuisance service requests because unsophisticated users/system administrators (SAs) ran into problems using fixed partition sizes, and they figured experienced SAs would never use the default anyway. - The decision was overly influenced by the Fedora community who didn't want that kind of complexity. - They just didn't know any better. - I think you get the idea. A lot of decisions that get made for defaults have little to do with what might be considered best in the industry. Mix and match as you choose. The team I worked on at EDS supported 800+ servers, almost all of them Red Hat. We _never_ used LVM for /. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/13/2008 at 9:47 PM, in message [EMAIL PROTECTED], Scott Rohling [EMAIL PROTECTED] wrote: -snip- And expansion of a root filesystem much harder. With a properly laid out file system design, that will _never_ be necessary. Never. As pointed out, RedHat defaults to an LVM root - so it's harder to brush it aside as just a bad idea. No, that doesn't make it harder at all. See my other post on that. I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. It's far worse than that. Having / on an LV has _zero_ advantages, since there is never a need to expand the root file system. Having / on an LV introduces additional risk, and will elongate recovery time. That makes the decision very easy. More risk, no benefit, no deal. Put / on an plain partition. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
On 8/14/2008 at 8:26 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. Laid out properly, / will never grow. # df -h FilesystemSize Used Avail Use% Mounted on /dev/dasda1 388M 168M 200M 46% / /dev/mapper/vg01-home 97M 4.4M 88M 5% /home /dev/mapper/vg01-opt 74M 21M 50M 30% /opt /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var Of course the amount of space dedicated to each LV will vary according to specific needs. The fundamental concept is the same, and will (hopefully) be the default on SLES11 if things go as I hope. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Basically I agree with you - put / on a fixed disk - but use LVM for the rest (/usr, /var/,/home/opt, /whatever). Can't say I agree that there is never an advantage though - in the world according to Scott and Mark where root should never have to increase - maybe .. but I'm always hesitant to use the word 'never' myself. Constantly bites me in the ass when I have to deal with other people's worlds.. ;-) Scott Rohling On Thu, Aug 14, 2008 at 2:28 PM, Mark Post [EMAIL PROTECTED] wrote: On 8/13/2008 at 9:47 PM, in message [EMAIL PROTECTED], Scott Rohling [EMAIL PROTECTED] wrote: -snip- And expansion of a root filesystem much harder. With a properly laid out file system design, that will _never_ be necessary. Never. As pointed out, RedHat defaults to an LVM root - so it's harder to brush it aside as just a bad idea. No, that doesn't make it harder at all. See my other post on that. I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. It's far worse than that. Having / on an LV has _zero_ advantages, since there is never a need to expand the root file system. Having / on an LV introduces additional risk, and will elongate recovery time. That makes the decision very easy. More risk, no benefit, no deal. Put / on an plain partition. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I like this. I also hope it becomes the default in SLES11. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Mark Post Sent: Thursday, August 14, 2008 1:36 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem On 8/14/2008 at 8:26 AM, in message [EMAIL PROTECTED], Ryan McCain [EMAIL PROTECTED] wrote: Thats the issue we are trying to avoid if possible. If we could put /, /opt, /usr, /lib, etc. etc. into LVM, we won't have to guestimate how much disk we'll need from the outset. We could grow as needed. Laid out properly, / will never grow. # df -h FilesystemSize Used Avail Use% Mounted on /dev/dasda1 388M 168M 200M 46% / /dev/mapper/vg01-home 97M 4.4M 88M 5% /home /dev/mapper/vg01-opt 74M 21M 50M 30% /opt /dev/mapper/vg01-srv 1.2G 1.1G 100M 92% /srv /dev/mapper/vg01-tmp 291M 34M 242M 13% /tmp /dev/mapper/vg01-usr 2.0G 901M 1.1G 45% /usr /dev/mapper/vg01-var 2.0G 608M 1.3G 32% /var Of course the amount of space dedicated to each LV will vary according to specific needs. The fundamental concept is the same, and will (hopefully) be the default on SLES11 if things go as I hope. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Mark Post wrote: On 8/13/2008 at 6:32 PM, in message [EMAIL PROTECTED], John Summerfield [EMAIL PROTECTED] wrote: -snip- Oh. Why does Red Hat default to using LVM? Since I work in NTS now, I can engage in some educated speculation, but speculation nonetheless: - The people who made this decision were never responsible for supporting hundreds of production servers in an enterprise - It eliminated a lot of nuisance service requests because unsophisticated users/system administrators (SAs) ran into problems using fixed partition sizes, and they figured experienced SAs would never use the default anyway. - The decision was overly influenced by the Fedora community who didn't want that kind of complexity. The choice of LVM by RH predates Fedora by some years, it was in RHL 7.3 for sure, and I don't think it was new then. - They just didn't know any better. - I think you get the idea. A lot of decisions that get made for defaults have little to do with what might be considered best in the industry. Mix and match as you choose. The team I worked on at EDS supported 800+ servers, almost all of them Red Hat. We _never_ used LVM for /. I've never seen a benefit to using LVM on /, and whether I do so depends on how I install (ks vs manual). Until now, I've never seen any suggestion that it's at all harmful, though I can imagine its use can create the same sorts of problems the use of filesystems labels can. Filesystems labels problems arise when one has one system and more than one install, where the may be more than one filesystem with the same name. The problem there is the (RH) implementation, not the use of labels itself. Linux doesn't care about duplicate names, it just uses the wrong one. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Scott Rohling wrote: I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. I think this is one of those topics that is endlessly debatable, so it's best just to list the pros and cons (and not just the cons) and leave it to the implementer to decide why they may or may not want to use LVM for root. DASD. Then - make your system unbootable (put an error in your /etc/fstab or zipl.conf or something) .. and then try and recover it with both an LVM and non-LVM root. These are the kinds of pros and cons you have to weigh yourself.. My Linux experience is principally on Intellish hardware. My favourite rescue disk is Knoppix, preferably the latest but in a pinch, whatever is to hand. It does not understand RH's LVM setup. OTOH RH/Fedora rescue CDs[1] do understand LVM and can mount the system needing rescue. How it would actually handle an incorrect fstab I don't know, but I would fully expect it to get the the point where I could apply a little vim (or sed or echo) and fix it. It's probably complicated to use an alternative standard system to rescue an LVM-rooted system (but maybe not if the alternative doesn't use LVM). I have seen problems discussed where duplicate volume/group names arose, in Fedora. [1] and presumably install media in rescue mode. In a mainframe environment I'd want to do as I did on OS/2, have a small utility/rescue system on hand for just such emergencies. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Scott Rohling wrote: Other than the virtual nature of the disks and that they aren't hardwired to the server, I don't see any reason to handle them differently than in the x86 world. They're no more dangerous on z/VM than they are anywhere else..Any of the reasons an LVM might 'go bad' on x86 applies to z/VM as well (and vice-a-versa).. Admittedly - it's probably easier to yank a disk away from a guest than it is to yank a hard drive out of an x86 server :-) A cure idea I came across on Intellish hardware was to create a _RAID_ group including a firewire drive. To backup system, insert drive sync remove drive Those are pretty easy to remove (and it's an idea that might be useful on mainframes too). Maybe using a virtual firewire drive:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
David Boyes wrote: 3) It complicates cloning and replication of system images in that if you use a template VG structure, it is difficult to be able to import a VG for repair in another system if all the VG names are the same (ie, you can't easily fix it if all your VGs are called system_vg, including the one in your recovery system). fyi Red Hat is moving from labelling filesystems to using UUIDs. I imagine it would be prudent for those cloning systems to include part that generates new UUIDs. You should also consider adding a script to your cloning process to change the default standard volume and group names to names that are unique. This would alleviate the problem of importing a VG for repair. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Ryan McCain wrote: Do you have every directory under / defined as its own filesystem? /etc, /boot, /var, /opt, /lib, etc.. ? Read the FHS which can be found at pathname.com. I don't think anyone's managed to put /boot on anything but a bare partition, at least on Intellish hardware. The system boot code has to be able to be found and able to find the kernel initial ramdisk. /lib must be in the root filesystem, as must some others: see the FHS for details. /usr can be ro and shared. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Rob van der Heij wrote: On Thu, Aug 14, 2008 at 5:30 PM, Fargusson.Alan [EMAIL PROTECTED] wrote: It is not the case the /boot is the issue. As soon as the kernel starts it mounts the root. If mounting the root fails then the kernel gives up, and you have to recover the root filesystem. The motivation to split off /boot stems from ancient PC hardware etc that required the boot stuff to be on low cylinder numbers. So you made a /boot partition that resides at the start of the disk. More recently, where / is defaults to LVM (and also if / or RAID), /boot cannot be in the root filesystem as the boot manager (grub) cannot navigate it. Probably, LILO can, because one runs the LILO command to build a list of blocks that must be read, but non of the distros I use defaults to LILO these days. If using two (identical) disks in a mirror arrangement, one can clone /boot from one to the other and so have both disks bootable. This has no relevance with Linux on z/VM (unless you want to do something like a 2nd IPL volume for Linux to back-out a kernel update, but that takes a bit more to do it right). Can one choose kernels at boot time on Zeds now? If so, that shouldn't be a problem. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this DJ - Original Message - From: Ryan McCain [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Root filesystem Date: Wed, 13 Aug 2008 16:14:12 -0500 How do you guys handle the / filesystem? Is it managed in LVM or outside of LVM? What are the pros and cons of doing it in and out? Thanks, Ryan -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
dave wrote: Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this Oh. Why does Red Hat default to using LVM? If LVM is so unreliable that it's risky to use it for one's root filesystem (which, in principle can easily be recovered if needs be), then how much more risky is it to use LVM for one's most valuables? chortle -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Hello! One could also ask why Slackware defaults to using one of the journal enabled file-systems as well. Although after reading user complaints regarding the problems with maintaining just such a file-system, then I will definitely agree with everyone about that decision. In fact for those of us who run that particular distribution, but certainly not for business, there's a document enclosed within the boot directory regarding why an initial root device blob needs to be created when using a journal enabled one. -- Gregg C Levine [EMAIL PROTECTED] The Force will be with you always. Obi-Wan Kenobi -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of John Summerfield Sent: Wednesday, August 13, 2008 9:32 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Root filesystem dave wrote: Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this Oh. Why does Red Hat default to using LVM? If LVM is so unreliable that it's risky to use it for one's root filesystem (which, in principle can easily be recovered if needs be), then how much more risky is it to use LVM for one's most valuables? chortle -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
Hi, John. I didn't say that LVMs are inherently risky or unreliable. By all means build and use LVMs to hold your application data and code. Just don't put the root Linux file system (the one Linux needs to boot from...) in an LVM. It makes recovery of a sick penguin in a z/VM environment must easier. - Original Message - From: John Summerfield [EMAIL PROTECTED] To: LINUX-390@VM.MARIST.EDU Subject: Re: Root filesystem Date: Thu, 14 Aug 2008 09:32:04 +0800 dave wrote: Hi, Ryan. Funny you should ask...this topic has just been discussed on this list:-) It's not a good idea to put your / file system on an LVM; if you ever have any problems with the LVM itself (e.g., a lost pv, say), then the Linux system can't be booted.. In other words, don't do this Oh. Why does Red Hat default to using LVM? If LVM is so unreliable that it's risky to use it for one's root filesystem (which, in principle can easily be recovered if needs be), then how much more risky is it to use LVM for one's most valuables? chortle -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Root filesystem
I didn't say that LVMs are inherently risky or unreliable. By all means build and use LVMs to hold your application data and code. Just don't put the root Linux file system (the one Linux needs to boot from...) in an LVM. It makes recovery of a sick penguin in a z/VM environment must easier. And expansion of a root filesystem much harder. As pointed out, RedHat defaults to an LVM root - so it's harder to brush it aside as just a bad idea. I think there are pros and cons - enough on both sides that I wouldn't flat out tell someone don't do it.. Recovery is less easy, yes, but certainly possible - you just have more than one DASD to consider. I think this is one of those topics that is endlessly debatable, so it's best just to list the pros and cons (and not just the cons) and leave it to the implementer to decide why they may or may not want to use LVM for root. I say there are good reasons to do it, so it should be something that is carefully considered. My best advice to the original appender is to try it.. and understand first-hand the differences. Fill up root and see if it's easier to add DASD to an LVM or move the whole fileystem to another DASD. Then - make your system unbootable (put an error in your /etc/fstab or zipl.conf or something) .. and then try and recover it with both an LVM and non-LVM root. These are the kinds of pros and cons you have to weigh yourself.. Scott Rohling -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
