Hi there, a while ago I reported reproducible extensive file system corruption.
In the meantime I have completely repartitioned the HD on which GNU/Hurd is located. Now it lives on /dev/hd2s1 in a 1,7 Gig primary partition. It has 400 MByte of swap space and 192 MByte RAM at its disposition on my K6/2 box. Before, I had suspected that something was wrong with my partition table. But that's definitely not the case now. Still, when programs extensively access the file system for reading or writing purposes, file system corruption is more or less guaranteed. Even the /etc/cron.daily/standard cron job makes my GNU/Hurd barf and reboot (when running find over the whole file system). In pptop I've observed that immediately before the hang/reboot, /hurd/ext2fs.static eats most CPU time. pptop further indicates a process size of more than 2 GByte for /hurd/ext2fs.static. Usually it is around 1,7 GByte. At reboot time, I always run into an 'unexpected inconsistency' and some if not many files are damaged or even truncated to length 0. I have typescripts of dumpe2fs and e2fsck available, if anyone would like to examine them, please let me know. BTW: The latest 'menu' package (2.0.8 ?!?) now builds cleanly and even *works* on GNU/Hurd. All I had to do was apt-get build dep and apt-get source -b. So if there is a running Hurd autobuilder anywhere, 'menu' should probably be queued up for building. Thanks, Johannes -- ~/.signature under construction
