Perry N. Myers
2008-Oct-09 04:08 UTC
[Ovirt-devel] image minimizer in ovirt-node-image kickstart
Noticed that there is a new section in the common-post.ks in ovirt-node-image using something call Image Minimizer. I assume this is the whitelist/blacklist solution that the AOS team has been working on? Some of the output from that is suspect... Here's what I'm seeing:> Running image-minimizer... > Unknown Command: touch > e2fsck 1.41.0 (10-Jul-2008) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > ovirt-node-image: 3724/35200 files (1.1% non-contiguous), 52460/140800 blocks > e2fsck 1.41.0 (10-Jul-2008) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > Directories count wrong for group #0 (441, counted=241). > Fix? yes > > > ovirt-node-image: ***** FILE SYSTEM WAS MODIFIED ***** > ovirt-node-image: 3724/14080 files (2.1% non-contiguous), 51098/51098 blocksDon't know if the resulting fsck is caused by the image minimizer or not, but if someone else can replicate what I'm seeing here we need to look into this. Also, the "Unknown command: touch" seems to be coming from the image minimizer as well. Perry
Jim Meyering
2008-Oct-09 06:20 UTC
[Ovirt-devel] image minimizer in ovirt-node-image kickstart
"Perry N. Myers" <pmyers at redhat.com> wrote:> Noticed that there is a new section in the common-post.ks in > ovirt-node-image using something call Image Minimizer. I assume this > is the whitelist/blacklist solution that the AOS team has been working > on? > > Some of the output from that is suspect... Here's what I'm seeing: > >> Running image-minimizer... >> Unknown Command: touch >> e2fsck 1.41.0 (10-Jul-2008) >> Pass 1: Checking inodes, blocks, and sizes >> Pass 2: Checking directory structure >> Pass 3: Checking directory connectivity >> Pass 4: Checking reference counts >> Pass 5: Checking group summary information >> ovirt-node-image: 3724/35200 files (1.1% non-contiguous), 52460/140800 blocks >> e2fsck 1.41.0 (10-Jul-2008) >> Pass 1: Checking inodes, blocks, and sizes >> Pass 2: Checking directory structure >> Pass 3: Checking directory connectivity >> Pass 4: Checking reference counts >> Pass 5: Checking group summary information >> Directories count wrong for group #0 (441, counted=241). >> Fix? yes >> >> >> ovirt-node-image: ***** FILE SYSTEM WAS MODIFIED ***** >> ovirt-node-image: 3724/14080 files (2.1% non-contiguous), 51098/51098 blocksI've seen that fsck-detected failure regularly, in the last couple days. I presume you're building on a system with at least 2 cores, right? I seem to recall that one fs-related phase was parallelized, so took advantage of all cores on a multi-core system, so maybe there's a race.> Don't know if the resulting fsck is caused by the image minimizer or > not, but if someone else can replicate what I'm seeing here we need to > look into this. > > Also, the "Unknown command: touch" seems to be coming from the image > minimizer as well.I proposed a work-around, then Alan proposed a better patch for that, but it was not possible to ACK with "works for me" yesterday, due to the early-boot problem you've just fixed.
Alan Pevec
2008-Oct-09 06:22 UTC
[Ovirt-devel] image minimizer in ovirt-node-image kickstart
Perry N. Myers wrote:> Noticed that there is a new section in the common-post.ks in > ovirt-node-image using something call Image Minimizer. I assume this is > the whitelist/blacklist solution that the AOS team has been working on?yes, it's in appliance-tools-002-3> Some of the output from that is suspect... Here's what I'm seeing: > >> Running image-minimizer... >> Unknown Command: touchyeah, Jim noticed that, [PATCH ovirt-node-image] move blacklisting into separate kickstart include should fix that> Don't know if the resulting fsck is caused by the image minimizer or > not, but if someone else can replicate what I'm seeing here we need to > look into this.does fsck happen if you apply above patch?