Bugzilla – Bug 300
Lookup while "mkisofs"ing a DVD-Image
Last modified: 2004-01-14 10:46:07 CST
When i try to create a DVD-Image with mkisofs (4.2 GB in size) i get a (most times) reproducable lookup at about 95% to 100% completition (6 out of 8 tries). This happens both with 2.4.24-pre3 (vanilla) and 2.4.23 + XFS-Patch. Nothing appears in the log-files and nothing appears on the screen (The 8 tries where with a freshly booted system on the console (no X11)). Compilers i tried: gcc-3.3.3(Debian Prerelease 20031229) and gcc-2.95.4 System is a Dual-P3-933Mhz, 3GB-RAM. The involved HDDs (both 100GB Western Digital, 7200RPM) are connected to a HighPoint RapidRAID 1540. The system is 3 years old and worked flawlessly with reiserfs for months.
Please strace the process to see where it's stopping, and if possible can you test it on a non-xfs filesystem as well? You could also get the kernel tree from oss.sgi.com cvs, this will include kdb and you could get a kernel backtrace to see where things are stuck. As it is, I don't think there's enough info to debug anything. Ah, one further thought... please include xfs_info output for the mount point you're using, this may be the large AG problem again.
Actually please include the xfs_info output first, this is simplest and will quickly rule out or confirm a specific problem, thanks.
Here is the xfs_info I formated the partition without further option to mkfs.xfs # xfs_info /dev/hdk1 meta-data=/x4 isize=256 agcount=16, agsize=1526339 blks = sectsz=512 data = bsize=4096 blocks=24421424, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=11924, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0
Testing with non-xfs partition. Before today i used reiserfs for month, worked flawlessly. (The last hardware-change is more than 3 month ago). Kernel 2.4.23 ran since about 1 week after it was released without problems. The first lockup was even with reiserfs as the source-partition after the first lookup i "converted" the source-partition to xfs. (Btw. "cp -av"ing 40GB of data went through without problems). Later i will try the other suggestions.
Ok, your allocation groups are > 4G (they are 5G or so) which means that file extents can grow past 4G, and this overflows the 32 bits that contain the length in an iomap structure. I'm working on the fix for this; if you want to re-mkfs and test with mkfs options to constrain the AGs to 4G or less, that should fix your problem in the meantime. (the -d agsize=4g option to mkfs)
95GB/16 = 5,9GB. Sure this is more than 4GB. :-( OK. I've recreated the filesystem with doubled agcount. meta-data=/x4 isize=256 agcount=32, agsize=763170 blks = sectsz=512 data = bsize=4096 blocks=24421438, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=11924, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 This also explains why "cp -av"ing the data around ("dump & restore") wasn't a problem because the biggest file copied was only(tm) 3,4 GB in size. <Recreating & filling the filesystem finished> Creating the DVD-Image hadn't crashed the machine (3 tries). I hope this was my first and last problem with XFS (knocking on wood). :-)
Created attachment 97 [details] Patch to fix large extents on large allocation groups The attached patch should resolve this bug
The attached patch should resolve this bug.