While compiling two kernels and untarring a third, my root fs was remounted r/w and I got the following in dmesg (kernel 2.4.19-pre9): EXT3-fs error (device ide0(3,2)) in ext3_new_inode: error 28 Aborting journal on device ide0(3,2). ext3_abort called EXT3-fs abort (device ide0(3,2)): ext3_journal_start: Detected aborted journal. Remounting filesystem read-only Remounting filesystem read-only EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in ext3_create: IO failure EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted EXT3-fs error (device ide0(3,2)) in start_transaction: Journal has aborted ... Rebooting didn't help: the journal aborted immediately. I also had some trouble using rootfstype=ext2 because (detecting that the filesystem was in a bad state when shutdown) it refused to mount the root fs ext2! Anyway, I finally tricked it into remounting as ext2. It then became clear that the disk was full. After removing a heap of files (possible because I was using ext2; not possible with ext3 because of the instant remounting as read-only) and rebooting, all was well. The moral of the story seems to be: ext3 behaves in an inelegant way when the disk is full. Is this inevitable for a journalling file system? If not, I for one would be very happy if ext3 (which otherwise I have been very happy with) behaved a little nicer in this case... All the best, Duncan.
