On Friday, 10/01/2021 at 08:20 GMT, "Aria Bamdad" <a...@bsc.gwu.edu> wrote: > It seems that there may be a problem with the new s390-tools chzdev command > at the least. Consider the following situation. You have a Linux guest > with root file system on device 150, usr on 151, var on 152. Then you make > a copy of these disk (DDR/flashcopy/Etc.), say you are cloning the guest. > The copied disks are now called F50, F51 and F52 respectively. Now consider > that you boot from your normal 15x disks while you have the F5x disks linked > and defined to the virtual machine. Then you use chzdev command to enable > any of the cloned disks, say F50 (clone of root). You can do this either > using commands like chzdev or via Yast DASD tool to activate. So far so > good. But if you then try to disable the same disk (F50) using chzdev (or > Yast DASD), chzdev complains with: > > Warning: ECKD DASD 0.0.0f50 is in use! > The following resources may be affected: > - Mount point / > Continue with operation? (yes/no) > > Well, it's neither in use (not mounted anywhere, just enabled), nor is it > the root mount point. The same will be true for F51 and F52. Chzdev states > that these are in use and mount points /usr and /var. This does not happen > when the disk is not a clone.
Traditionally the file systems mark the disks as 'in use' when they are mounted so that that message can be issued, among other things. Consequently, if you clone it while it's mounted, the clone will have the same marking and appear to be in use. IMO, cloning should be done with the file system unmounted. Once the disk is cloned, it's no longer the same disk in terms of content, but if memory serves, the logical volume manager remembers UUIDs so that it can automatically form the logical volume. If it were to see a desired UUID on a different disk, it could grab the wrong disk, resulting in a corrupted file system. Timing is everything. If you're cloning and immediately giving it to a different server, then it wouldn't make any difference since the "universe" of UUIDs is limited to what the server has access to. Alan Altmark Senior Managing z/VM and Linux Consultant IBM Systems Lab Services IBM Z Delivery Practice ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
