Re: Expand root filesystem, SLES 11

[Andrew Westerfield]

Ram,

I too have been working on copying the root filesystem to a larger volume.
And, like you, followed The Cookbook by originally allocating 372MB for root.

If you haven't figured it out yet, I'd like to offer some help and hopefully 
get you on the right path.

You moved root to a larger volume, right? But you also need to move the logical 
volume data, as Mark said, on that same old root disk over to a larger (or 
equal sized) volume.

You can either allocate a new minidisk OR you can use empty space on a unused 
disk partition (if large enough).

Let's say you have a new volume /dev/dasdz and the old logical volume data is 
in volume group linux-vg on /dev/dasdy

1. Create a new physical volume from /dev/dasdz using the pvcreate command.

2. Extend volume group linux-vg using the vgextend command to add /dev/dasdz to 
the volume group.

3. Move the LV data from /dev/dasdy over to /dev/dasdz using the pvmove command.

4. Once you've moved the data over to the new volume, you can remove /dev/dasdy 
from volume group linux-vg.

I hope this helps or even makes sense.

If anyone sees anything wrong with this or has a better method, please let me 
know. This method has worked for me.

Good luck!



Andrew Westerfield
Systems Specialist
MS Department of Information Technology Services
www.its.ms.gov



-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Wednesday, January 27, 2016 3:13 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

>>> On 1/27/2016 at 10:56 AM, Ram Jam  wrote:
> My apologies Mark. Will remember to post more info next time.
> Errors on the z/VM console are as follows when I boot up the Linux guest.
> --Scanning for LVM volume
> groups... Reading all
> physicalvolumes.  This may take a while... Found
> duplicate PVEBdleGPWJNX77h8jgpTskuXHtMUWfWPx: using /dev/dasdc1
> not/dev/dasdb1  Couldn't find devicewith uuid
> 'K6Ec0V-DClh-pFhp-vLAE-yWWf-ZH4u-GtVUIX'.Couldn't find devicewith
> uuid 'ecXHA7-CLLe-g3iN-mEeE-ayxE-KUOn-xtpmFe'.Couldn't find
> devicewith uuid 'ughcI9-ed8q-FQSX-GjJc-JVpn-yTBc-AP4fqK'.Couldn't
> find devicewith uuid 'gDK29H-4fsY-afS8-ARWW-bzqG-KTjK-3Y0GmT'.Found

OK, now we're getting somewhere.  The problem isn't the duplicate UUIDs, it's 
the missing ones.  Thinking about it, the Cookbook has you create a partition 
on the DASD volume containing the root file system to use for LVM.  So, that 
means we have more work to do than just moving the one partition.  We also need 
to move the contents of the PV to a new PV.

The other problem is, just what happened to the other disks that are providing 
these UUIDS:
K6Ec0V-DClh-pFhp-vLAE-yWWf-ZH4u-GtVUIX
ecXHA7-CLLe-g3iN-mEeE-ayxE-KUOn-xtpmFe
ughcI9-ed8q-FQSX-GjJc-JVpn-yTBc-AP4fqK
gDK29H-4fsY-afS8-ARWW-bzqG-KTjK-3Y0GmT

It looks like your non-root DASD volumes are not coming online.

When you have your system booted with the old root device, what does cat 
/proc/dasd/devices show, and what does it show with the new root device?

-snip-
> Also, do you mind explaining in a little more detail, maybe provide an
> example, of what my /etc/fstab should look like after Step 8 of your
> procedures?
> Mine looks like this:
> /dev/disk/by-path/ccw-0.0.0100-part1 / ext3   acl,user_xattr
> 1 1
> /dev/system-vg/opt-lv /opt ext3   acl,user_xattr
> 1 2
> /dev/system-vg/tmp-lv /tmp ext3   acl,user_xattr
> 1 2
> /dev/system-vg/usr-lv /usr ext3   acl,user_xattr
> 1 2
> /dev/system-vg/var-lv /var ext3   acl,user_xattr
> 1 2
> proc /procproc   defaults  0
> 0
> sysfs/sys sysfs noauto0
> 0
> debugfs  /sys/kernel/debugdebugfsnoauto0
> 0
> devpts   /dev/pts devpts mode=0620,gid=5   0
> 0

That's how it should look both before and after.  That's part of the beauty of 
VM.  If you swap out hardware but keep the same virtual device address, a lot 
of things in the guest don't have to be changed.


Mark Post

--
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/
DISCLAIMER: This email and any files transm

Re: Expand root filesystem, SLES 11

[Mark Post]

>>> On 1/27/2016 at 10:56 AM, Ram Jam  wrote: 
> My apologies Mark. Will remember to post more info next time.
> Errors on the z/VM console are as follows when I boot up the Linux guest.
> --Scanning for LVM volume 
> groups... Reading all 
> physicalvolumes.  This may take a while... Found 
> duplicate PVEBdleGPWJNX77h8jgpTskuXHtMUWfWPx: using /dev/dasdc1 
> not/dev/dasdb1  Couldn't find devicewith uuid 
> 'K6Ec0V-DClh-pFhp-vLAE-yWWf-ZH4u-GtVUIX'.Couldn't find devicewith 
> uuid 'ecXHA7-CLLe-g3iN-mEeE-ayxE-KUOn-xtpmFe'.Couldn't find 
> devicewith uuid 'ughcI9-ed8q-FQSX-GjJc-JVpn-yTBc-AP4fqK'.Couldn't 
> find devicewith uuid 'gDK29H-4fsY-afS8-ARWW-bzqG-KTjK-3Y0GmT'.Found 

OK, now we're getting somewhere.  The problem isn't the duplicate UUIDs, it's 
the missing ones.  Thinking about it, the Cookbook has you create a partition 
on the DASD volume containing the root file system to use for LVM.  So, that 
means we have more work to do than just moving the one partition.  We also need 
to move the contents of the PV to a new PV.

The other problem is, just what happened to the other disks that are providing 
these UUIDS:
K6Ec0V-DClh-pFhp-vLAE-yWWf-ZH4u-GtVUIX
ecXHA7-CLLe-g3iN-mEeE-ayxE-KUOn-xtpmFe
ughcI9-ed8q-FQSX-GjJc-JVpn-yTBc-AP4fqK
gDK29H-4fsY-afS8-ARWW-bzqG-KTjK-3Y0GmT

It looks like your non-root DASD volumes are not coming online.

When you have your system booted with the old root device, what does
cat /proc/dasd/devices
show, and what does it show with the new root device?

-snip-
> Also, do you mind explaining in a little more detail, maybe provide an 
> example, of what my /etc/fstab should look like after Step 8 of your 
> procedures?
> Mine looks like this:
> /dev/disk/by-path/ccw-0.0.0100-part1 / ext3   acl,user_xattr
> 1 1
> /dev/system-vg/opt-lv /opt ext3   acl,user_xattr
> 1 2
> /dev/system-vg/tmp-lv /tmp ext3   acl,user_xattr
> 1 2
> /dev/system-vg/usr-lv /usr ext3   acl,user_xattr
> 1 2
> /dev/system-vg/var-lv /var ext3   acl,user_xattr
> 1 2
> proc /procproc   defaults  0 
> 0
> sysfs/sys sysfs noauto0 
> 0
> debugfs  /sys/kernel/debugdebugfsnoauto0 
> 0
> devpts   /dev/pts devpts mode=0620,gid=5   0 
> 0

That's how it should look both before and after.  That's part of the beauty of 
VM.  If you swap out hardware but keep the same virtual device address, a lot 
of things in the guest don't have to be changed.


Mark Post

--
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: Expand root filesystem, SLES 11

[Mark Post]

>>> On 1/26/2016 at 11:19 AM, Ram Jam  wrote: 
> Errors during boot say duplicate PVs 
> 
> On Tuesday, January 26, 2016 10:01 AM, Ram Jam  wrote:
>  
> 
>  Mark,
> I followed your instructions exactly as described. However, I cannot get the 
> Linux guest to come back up. Error when trying to mount other disks.
> 
> My / file system lives on a ~372 MB partition /dev/dasda1
> The remainder of /dev/dasda and all of /dev/dasdb house /opt, /tmp, /usr/, 
> and /var (with LVM).
> 
> I'm thinking because the entirety of old minidisk 100 (/dev/dasda) is being 
> commented out when trying to boot the guest with the new / filesystem that 
> the system cannot locate /opt, /tmp, /usr, and /var as noted in /etc/fstab

Duplicate PVs shouldn't cause a failure, just warning messages.  LVM will pick 
one and keep on going.

If your new root file system has all the directories in it that the old one 
did, there shouldn't be any problems mounting the other file systems.  Check 
that they do exist.  My guess is that the directories that were mount points 
for the other file systems didn't get created, so it's possible that /dev, 
/opt, /proc, /sys, /tmp, /usr, and /var don't exist in the new file system.

If that's the case, mount the new root file system and issue mkdir commands for 
them.  Make sure the permissions are the same as the original.  On my system, 
/proc, /sys, and /tmp don't have the default 755 bits, so especially check 
those.

Finally, just reporting "it didn't work" and then saying why you think it 
didn't work isn't nearly as useful as posting the contents of the console log.  
:)  Since you're new to this, it helps us help you if we can see the actual 
output.  (Even if you weren't new, there's a good chance that _someone_ on the 
mailing list will spot something you missed.)  As a group, this mailing list 
has a good track record of figuring out problems.


Mark Post

--
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: Expand root filesystem, SLES 11

[Mark Post]

>>> On 1/25/2016 at 10:00 AM, Ram Jam  wrote: 
> New to the list. Extremely new to Linux and Z systems.
> 
> I need to expand the / filesystem on a server running SLES 11.3 (under z/VM 
> 6.3)
> 
> The server was built by my predecessor to the specifications outlined in the 
> Virtualization Cookbook for SLES 11.(/dev/dasda1 with 384 MB).
> / is rapidly approaching 100%
> Since / is not on LVM, how can I expand the / filesystem?
> I am thankful for any help or nudges in the right direction.

Others have set you on the path to resolving your current situation.  As you 
noticed, however, upgrading to SLES12 could be a much bigger problem with a 
relatively small root file system.  Partly this is due to grub2 now being used, 
which puts a fair amount of "stuff" under /boot/grub2.

The easiest way around this is to move to a different, larger, piece of disk 
for your root file system.
1. Allocate a new minidisk to the guest.
2. Bring it online to the system using chccwdev -e.
3. Run dasdfmt on it
4. Run fdasd on it
5. Run mkfs on it
6. Mount the file system, perhaps on /mnt
7. Change to /mnt (cd /mnt)
8. Use rsync to copy the root file system to this mountpoint
8a. rsync -lPprvtaxS / .
 You can leave the "v" off it you don't like watching the files fly by on 
your terminal.

At this point you have an exact copy of your root file system, EXCEPT for the 
fact that the pointers to the kernel, initrd, and parms have been written to it 
yet.  Before you do that, check things like /etc/zipl.conf and /etc/fstab to 
make sure that you have entries in them like /dev/disk/by-path and NOT 
/dev/dasda1, /dev/dasdb1, etc.  If you do, change them 
_to_the_virtual_device_number_of_your_existing_root_file_system.  NOT the 
current virtual device number it's has.  The reason for this is, you're going 
to have the z/VM systems programmer change the virtual device numbers so that 
your new minidisk will be the same as your current one, and the current one 
will be changed to something else until you're sure you can get rid of it.

You don't have /boot as a separate file system, so to continue:
9. Bind mount /dev, /proc, and /sys on /mnt:
9a. for fs in dev proc sys; do mount --bind /$fs /mnt/$fs; done
10. Chroot to /mnt
11. Run zipl
12. Make sure it finishes successfully.
13. Exit from the chroot
14. Unmount the file systems
14a. for fs in dev proc sys; do umount /mnt/$fs; done
15. Unmount the new root: umount /mnt
16. Shut down the guest: shutdown -h now
17. Logoff the guest
18. Have your z/VM systems programmer switch the virtual devices numbers for 
the old and new root file systems
19. Boot your system from the same virtual device number as before.

When you come up, you should have your larger file system in place.  Once 
you're satisfied that things look OK, you can detach the old minidisk and have 
the z/VM systems programmer remove it from the CP directory.

Disclaimer: I just typed this off the top of my head.  I haven't actually done 
it in quite a while, but I believe it should work as desired.  It's 
non-destructive so you can always go back to your previous setup.


Mark Post

--
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: Expand root filesystem, SLES 11

[Nix, Robert P.]

Run the command ³du -ckxs /*². This will give you the sizes of the
directories found in the root filesystem, and won¹t go down the mounted
filesystems. What are the largest directories found? This should be where
the problem lies.

Sample:

ts00086@clld0001026 /:0 $ sudo du -ckxs /*
30380   /apps
9432/bin
99739   /boot
4   /cgroup
192 /dev
33456   /etc
20  /home
399008  /lib
27676   /lib64
16  /lost+found
4   /media
4   /misc
8   /mnt
4   /net
397192  /opt
du: cannot access `/proc/6041/task/6041/fd/4': No such file or directory
du: cannot access `/proc/6041/task/6041/fdinfo/4': No such file or
directory
du: cannot access `/proc/6041/fd/4': No such file or directory
du: cannot access `/proc/6041/fdinfo/4': No such file or directory
0   /proc
504 /root
17272   /sbin
0   /selinux
4   /shares
324896  /sites
4   /srv
0   /sys
60  /tmp
4   /unixadm
4065560 /usr
1737336 /var
7142775 total
ts00086@clld0001026 /:1 $


(I¹m not sure the -x switch actually worked. But you know where your
filesystems are mounted, so ignore those.)

In this case, I have a /sites directory that has some space tied up in the
root filesystem, that could have been better controlled by placing it in
its own filesystem. /apps, /opt, /home, /boot, /var and /opt are their own
filesystems, so I can discount that usage. /bin, /etc, /lib, /lib64,
/sbin, /usr are fairly static, so I can generally ignore them as well. So,
my concern would be the /sites directory, and how I could move and isolate
it.
-- 
Robert P. Nix | Sr IT Systems Engineer | Data Center Infrastructure
Services

Mayo Clinic | 200 First Street SW | Rochester, MN 55905
507-284-0844 | nix.rob...@mayo.edu
"quando omni flunks moritati"




On 1/25/16, 9:34 AM, "Linux on 390 Port on behalf of Ram Jam"
 wrote:

>/home/opt/tmp/usr/var All have their own logical volume
>I will look into these option you both have provided. Am thankful for
>more options too.
> 
>
>On Monday, January 25, 2016 9:27 AM, "van Sleeuwen, Berry"
> wrote:
> 
>
> What is filling up your / filesystem? If it's rapidly filling up then I
>would expect a directory with RW data is in the / filesystem. Such as
>/home.
>
>The easiest would be to add a minidisk and move the directory that fills
>up into that new disk. Next mount that disk on that mountpoint. Usually
>you will already have directories such as /usr and /home on separate
>(mini)disks.
>
>Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
>Berry van Sleeuwen
>
>
>-Original Message-
>From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram
>Jam
>Sent: Monday, January 25, 2016 4:01 PM
>To: LINUX-390@VM.MARIST.EDU
>Subject: Expand root filesystem, SLES 11
>
>New to the list. Extremely new to Linux and Z systems.
>
>I need to expand the / filesystem on a server running SLES 11.3 (under
>z/VM 6.3)
>
>The server was built by my predecessor to the specifications outlined in
>the Virtualization Cookbook for SLES 11.(/dev/dasda1 with 384 MB).
>/ is rapidly approaching 100%
>Since / is not on LVM, how can I expand the / filesystem?
>I am thankful for any help or nudges in the right direction.
>Ram
>
>--
>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/
>This e-mail and the documents attached are confidential and intended
>solely for the addressee; it may also be privileged. If you receive this
>e-mail in error, please notify the sender immediately and destroy it. As
>its integrity cannot be secured on the Internet, Atos¹ liability cannot
>be triggered for the message content. Although the sender endeavours to
>maintain a computer virus-free network, the sender does not warrant that
>this transmission is virus-free and will not be liable for any damages
>resulting from any virus transmitted. On all offers and agreements under
>which Atos Nederland B.V. supplies goods and/or services of whatever
>nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply.
>The Terms of Delivery shall be promptly submitted to you on your request.
>
>
>
>--
>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
>---

Re: Expand root filesystem, SLES 11

[Davis, Jim [PRI-1PP]]

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Monday, January 25, 2016 11:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

I have checked my /lib in a SLES11 SP3 and it's some 70M. Your free size in / 
(some 100M) might be tight, depending on what SLES12 would need in there. Also 
I checked the content and I expect that will be required during boot so then 
it's not an option to move it to its own minidisks.

One other thing though. I know some installer processes can't handle separate 
minidisks during install. They only check the size of / and disregard the fact 
that some directories might be on separate volumes. Usually that error is due 
to the size required for /usr.

Cleaning the /lib/modules depends on what is in there. Indeed when old kernel 
files are present in /lib/modules and /boot then they might be removed but you 
need to be careful that they are indeed obsolete.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram Jam
Sent: Monday, January 25, 2016 4:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

Looks like /lib/modules is pretty large compared to other subdirectories.
Do you all think giving /lib its own filesystem would be a good idea?
Forgot to mention. I'm testing an upgrade to SLES 12 and I received an error 
about the / filling up. This prompted the search into expanding /.


This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

FW: Expand root filesystem, SLES 11

[Davis, Jim [PRI-1PP]]

Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.17.43.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Barracuda-Connect: mailgate2.mms.primerica.com[74.123.239.132]
X-Barracuda-Start-Time: 1453742446
X-Barracuda-URL: https://148.100.49.28:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at marist.edu
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=3.5 
QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.5 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.26435
Rule breakdown below
 pts rule name  description
 -- 
--

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZpcywgSmltIFtQUkktMVBQ
XSANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNSwgMjAxNiAxMjowNCBQTQ0KVG86ICdsaW51eC0z
OTBAdm0ubWFyaXN0LmVkdScNClN1YmplY3Q6IFJFOiBFeHBhbmQgcm9vdCBmaWxlc3lzdGVtLCBT
TEVTIDExDQoNClRoaXMgd2lsbCBub3QgaGVscCB5b3UgaW4geW91ciBjdXJyZW50IHNpdHVhdGlv
bi4NCg0KSSBhbHdheXMgYWxsb2NhdGUgYSBmdWxsIG1vZDMgdm9sdW1lIGFzIG15IHJvb3QgKGJv
b3QpIGRyaXZlLg0KQWZ0ZXIgdGhlIHN5c3RlbSBpcyBidWlsdCBJIGZpbGwgdGhlIC8gZGlyZWN0
b3J5IHdpdGggYSBkdW1teSBmaWxlIHN1Y2ggYXMgS0VSTkVMLkRDU1MuU0VHTUVOVCwgdGhhdCBp
cyBhbGwgYmxhbmtzIGJ1dCBlbmNyeXB0ZWQuDQpJdCBsb29rcyBsaWtlIGEgZmlsZSB3aXRoIGNv
ZGUgaXQgaXQuDQpObyBvbmUgaGFzIGJlZW4gYnJhdmUgZW5vdWdoIHRvIGRlbGV0ZSB0aGlzIGZp
bGUuDQoNCldoZW4gSSBkbyBtYWludGVuYW5jZSBJIGRlbGV0ZSB0aGlzIGZpbGUsIGRvIHRoZSB1
cGdyYWRlIG9yIG1haW50ZW5hbmNlIGFuZCBjbGVhbnVwIHRoZSAvIGRpcmVjdG9yeSBhbmQgcmVj
cmVhdGUgdGhlIEtFUk5FTC5EQ1NTLlNFR01FTlQgZmlsZS4NCg0KVGhpcyBrZWVwcyB0aGUgb3Ro
ZXIgU1UgdXNlcnMgd2hvIGxpa2UgdG8gaW5zdGFsbCBwcm9kdWN0cyBpbnRvIHRoZSAvIHVuZGVy
IGNvbnRyb2wgYXMgdGhlcmUgaXMgbm90IGVub3VnaCBzcGFjZSBhbmQgdGhleSBjYWxsIGFuZCB0
aGVuIGFyZSBpbmZvcm1lZCB0aGF0IHRoZXkgc2hvdWxkIGJlIGluc3RhbGxpbmcgaW50byAvdXNy
IG9yIC9vcHQgZGlyZWN0b3JpZXMuDQoNCkkgdHJpZWQgdG8gbWFrZSB0aGUgcm9vdCByL28gYnV0
IHNvbWUgU1UgdXNlcnMga25vdyBob3cgdG8gZGVmZWF0IHRoYXQsIGJ1dCBub25lIGhhdmUgZXZl
ciBkZWxldGVkIG15IEtFUk5FTC5EQ1NTLlNFR01FTlQgZmlsZS4NCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGludXggb24gMzkwIFBvcnQgW21haWx0bzpMSU5VWC0zOTBA
Vk0uTUFSSVNULkVEVV0gT24gQmVoYWxmIE9mIHZhbiBTbGVldXdlbiwgQmVycnkNClNlbnQ6IE1v
bmRheSwgSmFudWFyeSAyNSwgMjAxNiAxMTozNyBBTQ0KVG86IExJTlVYLTM5MEBWTS5NQVJJU1Qu
RURVDQpTdWJqZWN0OiBSZTogRXhwYW5kIHJvb3QgZmlsZXN5c3RlbSwgU0xFUyAxMQ0KDQpJIGhh
dmUgY2hlY2tlZCBteSAvbGliIGluIGEgU0xFUzExIFNQMyBhbmQgaXQncyBzb21lIDcwTS4gWW91
ciBmcmVlIHNpemUgaW4gLyAoc29tZSAxMDBNKSBtaWdodCBiZSB0aWdodCwgZGVwZW5kaW5nIG9u
IHdoYXQgU0xFUzEyIHdvdWxkIG5lZWQgaW4gdGhlcmUuIEFsc28gSSBjaGVja2VkIHRoZSBjb250
ZW50IGFuZCBJIGV4cGVjdCB0aGF0IHdpbGwgYmUgcmVxdWlyZWQgZHVyaW5nIGJvb3Qgc28gdGhl
biBpdCdzIG5vdCBhbiBvcHRpb24gdG8gbW92ZSBpdCB0byBpdHMgb3duIG1pbmlkaXNrcy4NCg0K
T25lIG90aGVyIHRoaW5nIHRob3VnaC4gSSBrbm93IHNvbWUgaW5zdGFsbGVyIHByb2Nlc3NlcyBj
YW4ndCBoYW5kbGUgc2VwYXJhdGUgbWluaWRpc2tzIGR1cmluZyBpbnN0YWxsLiBUaGV5IG9ubHkg
Y2hlY2sgdGhlIHNpemUgb2YgLyBhbmQgZGlzcmVnYXJkIHRoZSBmYWN0IHRoYXQgc29tZSBkaXJl
Y3RvcmllcyBtaWdodCBiZSBvbiBzZXBhcmF0ZSB2b2x1bWVzLiBVc3VhbGx5IHRoYXQgZXJyb3Ig
aXMgZHVlIHRvIHRoZSBzaXplIHJlcXVpcmVkIGZvciAvdXNyLg0KDQpDbGVhbmluZyB0aGUgL2xp
Yi9tb2R1bGVzIGRlcGVuZHMgb24gd2hhdCBpcyBpbiB0aGVyZS4gSW5kZWVkIHdoZW4gb2xkIGtl
cm5lbCBmaWxlcyBhcmUgcHJlc2VudCBpbiAvbGliL21vZHVsZXMgYW5kIC9ib290IHRoZW4gdGhl
eSBtaWdodCBiZSByZW1vdmVkIGJ1dCB5b3UgbmVlZCB0byBiZSBjYXJlZnVsIHRoYXQgdGhleSBh
cmUgaW5kZWVkIG9ic29sZXRlLg0KDQpNZXQgdnJpZW5kZWxpamtlIGdyb2V0L1dpdGgga2luZCBy
ZWdhcmRzL01pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4sIEJlcnJ5IHZhbiBTbGVldXdlbg0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMaW51eCBvbiAzOTAgUG9ydCBbbWFp
bHRvOkxJTlVYLTM5MEBWTS5NQVJJU1QuRURVXSBPbiBCZWhhbGYgT2YgUmFtIEphbQ0KU2VudDog
TW9uZGF5LCBKYW51YXJ5IDI1LCAyMDE2IDQ6NDQgUE0NClRvOiBMSU5VWC0zOTBAVk0uTUFSSVNU
LkVEVQ0KU3ViamVjdDogUmU6IEV4cGFuZCByb290IGZpbGVzeXN0ZW0sIFNMRVMgMTENCg0KTG9v
a3MgbGlrZSAvbGliL21vZHVsZXMgaXMgcHJldHR5IGxhcmdlIGNvbXBhcmVkIHRvIG90aGVyIHN1
YmRpcmVjdG9yaWVzLg0KRG8geW91IGFsbCB0aGluayBnaXZpbmcgL2xpYiBpdHMgb3duIGZpbGVz
eXN0ZW0gd291bGQgYmUgYSBnb29kIGlkZWE/DQpGb3Jnb3QgdG8gbWVudGlvbi4gSSdtIHRlc3Rp
bmcgYW4gdXBncmFkZSB0byBTTEVTIDEyIGFuZCBJIHJlY2VpdmVkIGFuIGVycm9yIGFib3V0IHRo
ZSAvIGZpbGxpbmcgdXAuIFRoaXMgcHJvbXB0ZWQgdGhlIHNlYXJjaCBpbnRvIGV4cGFuZGluZyAv
Lg0KDQoNClRoaXMgZS1tYWlsIGFuZCB0aGUgZG9jdW1lbnRzIGF0dGFjaGVkIGFyZSBjb25maWRl
bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZTsgaXQgbWF5IGFsc28g
YmUgcHJpdmlsZWdlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz
ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVzdHJveSBpdC4gQXMgaXRzIGlu
dGVncml0eSBjYW5ub3QgYmUgc2VjdXJlZCBvbiB0aGUgSW50ZXJuZXQsIEF0b3PigJkgbGlhYmls
aXR5IGNhbm5vdCBiZSB0cmlnZ2VyZWQgZm9yIHRoZSBtZXNzYWdlIGNvbnRlbnQuIEFsdGhvdWdo
IHRoZSBzZW5kZXIgZW5kZWF2b3VycyB0byBtYWludGFpbiBhIGNvbXB1dGVyIHZpcnVzLWZyZWUg
bmV0d29yaywgdGhlIHNlbmRlciBkb2VzIG5vdCB3YXJyYW50IHRoYXQgdGhpcyB0cmFuc21pc3Np
b24gaXMgdmly

Re: Expand root filesystem, SLES 11

[Davis, Jim [PRI-1PP]]

This will not help you in your current situation.

I always allocate a full mod3 volume as my root (boot) drive.
After the system is built I fill the / directory with a dummy file such as 
KERNEL.DCSS.SEGMENT, that is all blanks but encrypted.
It looks like a file with code it it.
No one has been brave enough to delete this file.

When I do maintenance I delete this file, do the upgrade or maintenance and 
cleanup the / directory and recreate the KERNEL.DCSS.SEGMENT file.

This keeps the other SU users who like to install products into the / under 
control as there is not enough space and they call and then are informed that 
they should be installing into /usr or /opt directories.

I tried to make the root r/o but some SU users know how to defeat that, but 
none have ever deleted my KERNEL.DCSS.SEGMENT file.


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of van 
Sleeuwen, Berry
Sent: Monday, January 25, 2016 11:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

I have checked my /lib in a SLES11 SP3 and it's some 70M. Your free size in / 
(some 100M) might be tight, depending on what SLES12 would need in there. Also 
I checked the content and I expect that will be required during boot so then 
it's not an option to move it to its own minidisks.

One other thing though. I know some installer processes can't handle separate 
minidisks during install. They only check the size of / and disregard the fact 
that some directories might be on separate volumes. Usually that error is due 
to the size required for /usr.

Cleaning the /lib/modules depends on what is in there. Indeed when old kernel 
files are present in /lib/modules and /boot then they might be removed but you 
need to be careful that they are indeed obsolete.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen, Berry van 
Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram Jam
Sent: Monday, January 25, 2016 4:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

Looks like /lib/modules is pretty large compared to other subdirectories.
Do you all think giving /lib its own filesystem would be a good idea?
Forgot to mention. I'm testing an upgrade to SLES 12 and I received an error 
about the / filling up. This prompted the search into expanding /.


This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: Expand root filesystem, SLES 11

[van Sleeuwen, Berry]

I have checked my /lib in a SLES11 SP3 and it's some 70M. Your free size in / 
(some 100M) might be tight, depending on what SLES12 would need in there. Also 
I checked the content and I expect that will be required during boot so then 
it's not an option to move it to its own minidisks.

One other thing though. I know some installer processes can't handle separate 
minidisks during install. They only check the size of / and disregard the fact 
that some directories might be on separate volumes. Usually that error is due 
to the size required for /usr.

Cleaning the /lib/modules depends on what is in there. Indeed when old kernel 
files are present in /lib/modules and /boot then they might be removed but you 
need to be careful that they are indeed obsolete.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram Jam
Sent: Monday, January 25, 2016 4:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

Looks like /lib/modules is pretty large compared to other subdirectories.
Do you all think giving /lib its own filesystem would be a good idea?
Forgot to mention. I'm testing an upgrade to SLES 12 and I received an error 
about the / filling up. This prompted the search into expanding /.


This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: Expand root filesystem, SLES 11

[van Sleeuwen, Berry]

Ah, that would explain why the / filesystem is filling up quickly.

Would the sizing from the cookbook support the upgrade processes? I expect the 
sizing was created for a fresh install. It might be the disk is too small to 
hold the required files during the upgrade. Some 300M would be enough to hold a 
required data for a Linux system but during an upgrade more space is needed.

I don't know if files in /lib are used during boot. If so then the boot will 
fail. If not then the directory might be eligible to be moved into its own 
minidisk. I have never tried that.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram Jam
Sent: Monday, January 25, 2016 4:44 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Expand root filesystem, SLES 11

Looks like /lib/modules is pretty large compared to other subdirectories.
Do you all think giving /lib its own filesystem would be a good idea?
Forgot to mention. I'm testing an upgrade to SLES 12 and I received an error 
about the / filling up. This prompted the search into expanding /.


This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: Expand root filesystem, SLES 11

[Michael MacIsaac]

Also: df -h

On Mon, Jan 25, 2016 at 10:37 AM, Michael MacIsaac 
wrote:

> What is the output of: du -sm /*
>
> -Mike M
>
> On Mon, Jan 25, 2016 at 10:25 AM, van Sleeuwen, Berry <
> berry.vansleeu...@atos.net> wrote:
>
>> What is filling up your / filesystem? If it's rapidly filling up then I
>> would expect a directory with RW data is in the / filesystem. Such as /home.
>>
>> The easiest would be to add a minidisk and move the directory that fills
>> up into that new disk. Next mount that disk on that mountpoint. Usually you
>> will already have directories such as /usr and /home on separate
>> (mini)disks.
>>
>> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
>> Berry van Sleeuwen
>>
>>
>> -Original Message-
>> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
>> Ram Jam
>> Sent: Monday, January 25, 2016 4:01 PM
>> To: LINUX-390@VM.MARIST.EDU
>> Subject: Expand root filesystem, SLES 11
>>
>> New to the list. Extremely new to Linux and Z systems.
>>
>> I need to expand the / filesystem on a server running SLES 11.3 (under
>> z/VM 6.3)
>>
>> The server was built by my predecessor to the specifications outlined in
>> the Virtualization Cookbook for SLES 11.(/dev/dasda1 with 384 MB).
>> / is rapidly approaching 100%
>> Since / is not on LVM, how can I expand the / filesystem?
>> I am thankful for any help or nudges in the right direction.
>> Ram
>>
>> --
>> 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/
>> This e-mail and the documents attached are confidential and intended
>> solely for the addressee; it may also be privileged. If you receive this
>> e-mail in error, please notify the sender immediately and destroy it. As
>> its integrity cannot be secured on the Internet, Atos’ liability cannot be
>> triggered for the message content. Although the sender endeavours to
>> maintain a computer virus-free network, the sender does not warrant that
>> this transmission is virus-free and will not be liable for any damages
>> resulting from any virus transmitted. On all offers and agreements under
>> which Atos Nederland B.V. supplies goods and/or services of whatever
>> nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply.
>> The Terms of Delivery shall be promptly submitted to you on your request.
>>
>
>

--
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: Expand root filesystem, SLES 11

[Michael MacIsaac]

What is the output of: du -sm /*

-Mike M

On Mon, Jan 25, 2016 at 10:25 AM, van Sleeuwen, Berry <
berry.vansleeu...@atos.net> wrote:

> What is filling up your / filesystem? If it's rapidly filling up then I
> would expect a directory with RW data is in the / filesystem. Such as /home.
>
> The easiest would be to add a minidisk and move the directory that fills
> up into that new disk. Next mount that disk on that mountpoint. Usually you
> will already have directories such as /usr and /home on separate
> (mini)disks.
>
> Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
> Berry van Sleeuwen
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram
> Jam
> Sent: Monday, January 25, 2016 4:01 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Expand root filesystem, SLES 11
>
> New to the list. Extremely new to Linux and Z systems.
>
> I need to expand the / filesystem on a server running SLES 11.3 (under
> z/VM 6.3)
>
> The server was built by my predecessor to the specifications outlined in
> the Virtualization Cookbook for SLES 11.(/dev/dasda1 with 384 MB).
> / is rapidly approaching 100%
> Since / is not on LVM, how can I expand the / filesystem?
> I am thankful for any help or nudges in the right direction.
> Ram
>
> --
> 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/
> This e-mail and the documents attached are confidential and intended
> solely for the addressee; it may also be privileged. If you receive this
> e-mail in error, please notify the sender immediately and destroy it. As
> its integrity cannot be secured on the Internet, Atos’ liability cannot be
> triggered for the message content. Although the sender endeavours to
> maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted. On all offers and agreements under
> which Atos Nederland B.V. supplies goods and/or services of whatever
> nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply.
> The Terms of Delivery shall be promptly submitted to you on your request.
>

--
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: Expand root filesystem, SLES 11

[van Sleeuwen, Berry]

What is filling up your / filesystem? If it's rapidly filling up then I would 
expect a directory with RW data is in the / filesystem. Such as /home.

The easiest would be to add a minidisk and move the directory that fills up 
into that new disk. Next mount that disk on that mountpoint. Usually you will 
already have directories such as /usr and /home on separate (mini)disks.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen


-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ram Jam
Sent: Monday, January 25, 2016 4:01 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Expand root filesystem, SLES 11

New to the list. Extremely new to Linux and Z systems.

I need to expand the / filesystem on a server running SLES 11.3 (under z/VM 6.3)

The server was built by my predecessor to the specifications outlined in the 
Virtualization Cookbook for SLES 11.(/dev/dasda1 with 384 MB).
/ is rapidly approaching 100%
Since / is not on LVM, how can I expand the / filesystem?
I am thankful for any help or nudges in the right direction.
Ram

--
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/
This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

Re: root filesystem on the NFS

[Grzegorz Powiedziuk]

2014-08-28 12:55 GMT-04:00 Grzegorz Powiedziuk :

> 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/

root filesystem on the NFS

[Grzegorz Powiedziuk]

Hello,
It is possible that it's nothing special and it has been already discussed
and done by this group over here many times and I just missed it. But I
thought that I will share what I came up with you anyway. Nothing big but
it might be interesting for some people.

Anyone of you tried running linux guests with a root filesystem on the NFS?
The goal was to have a "cheap" linux systems s390, practically disk less
for less critical tasks. Moreover, root on the NFS gives some flexibility
in terms of doing service on such guest. Having access to system's root
file system with one command (mount -t nfs  ) even when it is down or
somewhat broken is pretty cool.
Of course, performance of NFS share will be worse that local 3390 but
system disk with a root filesystem usually doesn't do much IOPs. And still,
you can have additional device for your data on any other type of storage
(dasd,fcp,nfs).
And honestly, It does not boot much slower than any other zLinux guest we
have over here.

Cloning such system also is quite fun...practically you can do it with a
simple "cp".  Most of nfs shares comes from NAS devices nowadays and most
of those are pretty safe and give you direct access to snapshots.
Imagine something like that:
- oops, I've just removed all my shadow files. That's ok, they are still in
/.snapshot/../etc directory.

People I work for asked me come up with such a "demo" system so I did. And
it is pretty cool so I though I could share it with others.

Anyway, I do it by doing an IPL from the reader of the kernel, modified
initramfs (which includes networking and NFS modules)  and of course
parmfile which specifies network settings and NFS location of the root
filesystem.

The initramfs initiates network, mounts the NFS root filesystem and
progresses with standard boot like any other linux system.

The minidisk with kernel, initrd, parmfile can be shared R/O across many
virtual machines (well, parmfile should be generated dynamically but that
will be easy).

Anyway, so far it works and we like it. I haven't done any serious
load/application tests yet but it looks promising.

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.

thanks
regards

Grzegorz (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

[Mark Perry]

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]

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

[Fargusson.Alan]

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

[Michael MacIsaac]

> 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

[Carsten Otte]

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  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

[Carsten Otte]

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

[Mark Perry]

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

[John Summerfield]

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 error switches to ReadOnly

[Mark Post]

>>> 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

[Rob van der Heij]

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

[John Summerfield]

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

[Fargusson.Alan]

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

[David Boyes]

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

[van Sleeuwen, Berry]

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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are con

Re: Root filesystem error switches to ReadOnly

[James Tison]

> 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 Perry]

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

[van Sleeuwen, Berry]

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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen

Re: Root filesystem error switches to ReadOnly

[Mark Perry]

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

[van Sleeuwen, Berry]

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
ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this transmission 
is virus-free and will not be

liable for any damages resulting from 
any virus transmitted.

 

On all offers and agreements under 
which Atos Origin supplies goods and/or

services of whatever nature, the Terms 
of Delivery from Atos Origin

exclusively apply. 

The Terms of Delivery shall be promptly 

Re: Root filesystem error switches to ReadOnly

[Mark Perry]

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

Root filesystem error switches to ReadOnly

[van Sleeuwen, Berry]

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. 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?
 
The guest is a SLES10 SP2.
 
[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?
 

Met vriendelijke groet/With kind regards, 
Berry van Sleeuwen 
Flight Forum 3000 5657 EW Eindhoven

( +31 (0)6 22564276

 



Atos Origin  

MO OC Mainframe Services

 

 

 

 
<><>ÿþDit bericht is vertrouwelijk en kan 
geheime informatie bevatten enkel

bestemd voor de geadresseerde. Indien 
dit bericht niet voor u is bestemd,

verzoeken wij u dit onmiddellijk aan 
ons te melden en het bericht te

vernietigen.

Aangezien de integriteit van het 
bericht niet veilig gesteld is middels

verzending via internet, kan Atos 
Origin niet aansprakelijk worden 
gehouden

voor de inhoud daarvan.

Hoewel wij ons inspannen een virusvrij 
netwerk te hanteren, geven

wij geen enkele garantie dat dit 
bericht virusvrij is, noch aanvaarden 
wij

enige aansprakelijkheid voor de 
mogelijke aanwezigheid van een virus in 
dit

bericht.

 

Op al onze rechtsverhoudingen, 
aanbiedingen en overeenkomsten 
waaronder

Atos Origin goederen en/of diensten 
levert zijn met uitsluiting van alle

andere voorwaarden de 
Leveringsvoorwaarden van Atos Origin 
van toepassing.

Deze worden u op aanvraag direct 
kosteloos toegezonden.

 

This e-mail and the documents attached 
are confidential and intended solely

for the addressee; it may also be 
privileged. If you receive this e-mail

in error, please notify the sender 
immediately and destroy it.

As its integrity cannot be secured on 
the Internet, the Atos Origin group

liability cannot be triggered for the 
message content. Although the

sender endeavours to maintain a 
computer virus-free network, the sender

does not warrant that this tra

Re: Root filesystem

[Scott Rohling]

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

[Mark Post]

>>> 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

[Mark Perry]

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

[Mark Post]

>>> 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

[Scott Rohling]

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

[Ryan McCain]

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

[Fargusson.Alan]

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

[Fargusson.Alan]

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

[Fargusson.Alan]

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

[Ryan McCain]

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

[David Boyes]

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

[Ryan McCain]

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

[Scott Rohling]

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

[Fargusson.Alan]

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

[Scott Rohling]

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

[Mark Post]

>>> 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

[Mark Post]

>>> 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

[Fargusson.Alan]

This only works if you have the tool that will change the UUID.  Around here we 
have to do everything manually.  I have no idea how I would change the UUID 
during the cloning process.  Even if I did it is one more thing to remember to 
do.

We don't use Red Hat, do I guess I don't have to worry.

-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
John Summerfield
Sent: Thursday, August 14, 2008 8:47 PM
To: LINUX-390@VM.MARIST.EDU
Subject: 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

__

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

[Fargusson.Alan]

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

[Ryan McCain]

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

[Ryan McCain]

> 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

[David Boyes]

> 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

[Richard Gasiorowski]

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 
08/14/2008 11:54 PM
Please respond to
Linux on 390 Port 


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

[Mark Perry]

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

[John Summerfield]

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

[John Summerfield]

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

[John Summerfield]

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

[John Summerfield]

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

[John Summerfield]

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

[John Summerfield]

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

[Fargusson.Alan]

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

[Scott Rohling]

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

[Mark Post]

>>> 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

[Mark Post]

>>> 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

[Mark Post]

>>> 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

[David Boyes]

> 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.

I use a very similar approach to Jay, with /home, /var and /srv in a
separate VG. I separate /etc into a separate VG (because that's where
all the stuff that makes a server unique exists), but put a minimal /etc
on the / partition to allow the system to come up to the point where I
can overmount the other stuff. 

A system looks something like this: 

/ = non-LVM partition, separate minidisk, about 5-10M, basic /sbin,
/bin, /etc
Production /opt, /usr, /lib, and /bin = system_vg
Production /home, /var, /srv = data_vg
Production /tmp = temp_vg
Production /etc = config_vg
 
> Split this way - the / should not really grow by more than 10%,  if at
> all,
> due to applying security fixes.

Exactly. 

--
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

[Fargusson.Alan]

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

[Ryan McCain]

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

[Scott Rohling]

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

[Fargusson.Alan]

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

[Robert J Brenneman]

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

[Scott Rohling]

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

[Ryan McCain]

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

[David Boyes]

> 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

[Ryan McCain]

> 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

[Ryan McCain]

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

[Scott Rohling]

<[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

[Kim Goldenberg]

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

[Fargusson.Alan]

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]

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

[Christian Langer]

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

[Fargusson.Alan]

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

[David Boyes]

> 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

[Robert J Brenneman]

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

[Rob van der Heij]

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

[Rob van der Heij]

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

[Fargusson.Alan]

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

[Fargusson.Alan]

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?
>>
>> 
>>
>>
>>
>> --
>>
>> 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

[Ryan McCain]

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

[Robert J Brenneman]

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

[Ryan McCain]

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

[Ryan McCain]

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?
>>
>> 
>>
>>
>>
>> --
>>
>> 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

[Scott Rohling]

>
> 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

Re: Root filesystem

[dave]

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?
>
> 
>
>
>
> --
>
> 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