Sparse files are really bad... not only
it takes ages to mkfs on them but you can get journal aborts and
remounting the FS read-only under heavier disk load in the guest! Use them only
for testing purposes and/or when you are really low on
space.
Daniel
I'm trying to troubleshoot a problem where mkfs commands take a
really, really long time to complete in my Xen guests.
I'm
using sparse file-backed images created using the 'virt-install' command on RHEL
5.1 x86_64. I'm kickstarting paravirtualized RHEL 4.5 and 5.1 x86_64
guests and they are going through a standard, unattended install with a common
diskmap. When they get to formatting the various local disks, all file
system formats are taking unfeasibly long. A 20+ GB file system takes
upwards of 20 minutes to run an mkfs on. During the mkfs, the underlying
filesystem on the DOM0 shows high utilization via iostat (upwards on 99%
utilization), but still the mkfs is horribly, horribly slow. mkfs is
horribly slow whether I use a GFS, ext3 or NFS underlying filesystem, so I don't
think that is the issue here.
If I create a non-sparse disk image or a
physical partition or logical volume, formatting times are drastically
increased. However, I'm trying to be judicious with overall storage
utilization and flexibility, I would very much like to stick with sparse
files.
Any advice on how I can troubleshoot this further or possibly find
a solution? Is there another local disk driver I can use besides "tap:aio"
(like "file") during the install process?
Note: My underlying
storage devices are Fibre Channel Hitachi OPEN-V*3 disks if it helps at all.
--
Dave Costakos
mailto:
david.costakos@gmail.com
