filesystem hosed once more...
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
Reply to: