Hi there, System is FreeBSD 4.9 Stable Had a problem during a portupgrade that when portupgrade did some cleaning a directory could not be deleted because it were not empty. However, it was empty. rm -rf didn't help either. Because I didn't know what to do I decided to boot. At system startup fsck was started which produced the message: unexpected softupdate inconsistency and also that some blocks could not be written to. At the end fsck said: filesystem still dirty and I should run fsck manually which I did but without any success. After that I rebooted from CD and did two backups of the filesystem using dump and tar. Both commands complained at the locations where the file system was corrupt but the backup went fine besides that. I checked for hardware errors by running dd if=/dev/ad0s1g of=/dev/null bs=32k Ran fine without any complains. After recreating the filesystem with newfs and restoring the data I'm fine for now. I should mention that I did not find any related messages in /var/log/messages. However, I'm really worried. Is there anybody I could do??? -- Manfred
In situations like this it can be useful to use vim on the dir entry that is affected and remove the invalid filenames. This has worked for me before. Cheers, Mark On Wed, 2004-03-10 at 17:27, Manfred Lotz wrote:> Hi there, > System is FreeBSD 4.9 Stable > > Had a problem during a portupgrade that when portupgrade did some > cleaning a directory could not be deleted because it were not empty. > However, it was empty. rm -rf didn't help either. > > Because I didn't know what to do I decided to boot. > > At system startup fsck was started which produced the message: unexpected > softupdate inconsistency and also that some blocks could not be written > to. At the end fsck said: filesystem still dirty and I should run fsck > manually which I did but without any success. > > After that I rebooted from CD and did two backups of the filesystem using > dump and tar. Both commands complained at the locations where the file > system was corrupt but the backup went fine besides that. > > I checked for hardware errors by running > dd if=/dev/ad0s1g of=/dev/null bs=32k > Ran fine without any complains. > > After recreating the filesystem with newfs and restoring the data I'm fine > for now. > > I should mention that I did not find any related messages in > /var/log/messages. > > > However, I'm really worried. Is there anybody I could do???-- Mark Sergeant <msergeant@snsonline.net> SNSOnline Technical Services -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040310/a60cf148/attachment.bin
Manfred Lotz wrote:> At system startup fsck was started which produced the message: unexpected > softupdate inconsistency and also that some blocks could not be written > to. At the end fsck said: filesystem still dirty and I should run fsck > manually which I did but without any success.I have a large EIDE drive (30 gigs) with a large partition on it that was getting unexpected softupdate inconsistency on it when I did large writes (untar, remove, installworld, etc..). I turned off softupdates, and that did not help, so I turned off dma and just went to PIO mode. Things got much better from then on, however performance was miserable in PIO mode, so I took a chance and upgraded to -CURRENT to get atang. It now works great in -current with dma+soft updates. I'm assuming this was a incompatibility/bug between my controller and -STABLE, otherwise I would see a littering of complaints in stable mailing list. I found one pr in gnats mentioning one such incompatibility and softupdate inconsistencies. For reference: atapci0: <ServerWorks ROSB4 UDMA33 controller> port 0xfc90-0xfc9f at device 15.1 on pci0 [root]$ atacontrol mode 0 Master = UDMA33 Slave = BIOSPIO [root]$ atacontrol list ATA channel 0: Master: ad0 <ST330630A/3.21> ATA/ATAPI rev 4 Slave: no device present the best test I could find for this was grabbing a large tarball, extracting it and then comparing the extraction 30 seconds later with the tar '-d' switch.> However, I'm really worried. Is there anybody I could do???Try performing the tar test above (I used the openoffice 1.1 source tarball from ports which failed the compare everytime), and if you get differences then try booting up a 5.2.1 cd, mount your UFS r/w partition and try the tar test again to see if it's still there. If so, I would recommend a source upgrade to 5.2.1 or -current. -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired);
msergeant@snsonline.net said:> In situations like this it can be useful to use vim on the dir entry > that is affected and remove the invalid filenames. This has worked for > me before.I'm astounded. Directories are not supposed to be modifiable by user-space processes at all, only with link/unlink/creat/etc system calls, because the risk of filesystem corruption is huge. What does vim do here that rm doesn't? And how does it get around the "cant write(2) directories" ban? See man open: [EISDIR] The named file is a directory, and the arguments spec- ify it is to be opened for writing.
oberman@es.net said:> emacs and XEmacs dired has been able to manipulate directories for as > ling as I've been around. I assume that they DO use the standard > system calls. (This includes vim, which I don't use.)True. I use dired a bit. There are also gui Windows Explorer or Norton Commander workalikes that also presumably use the same system calls. The key phrase here is "What does vim do here _that rm doesn't_?" If vim is also just using unlink() then rm can (theoretically) do the job just as well. It seems like really odd advice to say "use vim because rm can't do the job." If this were in any way true, then I'd call that a serious bug in rm.
On Wed, 10 Mar 2004, othermark wrote:> For reference: > atapci0: <ServerWorks ROSB4 UDMA33 controller> port 0xfc90-0xfc9f at device > 15.1 on pci0This controller is known to cause data corruption when used in DMA mode. Use a different controller, or PIO. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org