Re: 5.2-BETA: giving up on 4 buffers (ata)
On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thu, 27 Nov 2003, Stefan Ehmann wrote: On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thu, Nov 27, 2003 a.d., Bruce Evans wrote: This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. I positively know that the given up buffers are the ones got with bread() in compute_sb_data() (ext2_vfsops:481). I doesn't matter if the mount is rw or ro. The comments in fs.h:155 suggests they will be released by biodone, but this doesn't happen :-) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thursday 27 November 2003 10:43, Stefan Ehmann wrote: On Wed, 2003-11-26 at 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I have this same problem, but I only have ufs1 partitions, all mounted r/w. It seemed to appear about 3 weeks ago, so there has to be a commit in this timeframe that caused it. An extra inconvenience is that I always lose one or two files when I shutdown due to ATA write caching - if I turn it off, I don't lose files, but my system is too slow. Doing a manual 'sync' before shutting down seems to help. Arjan pgp0.pgp Description: signature
5.2-BETA: giving up on 4 buffers (ata)
Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... Regards, -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. I have observed the following: System dies leaving the file systems dirty. (File systems have soft-updates enabled.) I reboot to single user and fsck all partitions including the root. I halt or reboot. I get a number of dirty buffers and the syncer eventually gives up. If I issue a mount -u / before shutting down, the problem does not occur. Why I should be able to get dirty buffers on a file system that has never been mounted as RW, I don't understand, but I see it every time I reboot after a crash. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Matthias Andree wrote:
when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on
flushing 4 dirty blocks.
This is easy to reproduce, but apparently uninteresting to the developers:
Reboot to single user, run full fsck, halt.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
In message [EMAIL PROTECTED], Kevin Oberman writes: Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. Why do you think it has anything to do with GEOM ? When we give up on buffers, then superblocks are likely victims, in particular when softupdates dependencies are involved. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Kevin Oberman [EMAIL PROTECTED] writes: Date: Wed, 26 Nov 2003 19:37:45 +0100 From: Matthias Andree [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... This looks like a GEOM related issue, although I am not completely sure of this. I have observed the following: System dies leaving the file systems dirty. (File systems have soft-updates enabled.) I reboot to single user and fsck all partitions including the root. I halt or reboot. I get a number of dirty buffers and the syncer eventually gives up. If I issue a mount -u / before shutting down, the problem does not occur. Why I should be able to get dirty buffers on a file system that has never been mounted as RW, I don't understand, but I see it every time I reboot after a crash. It happened to me many times on various machines. Some running 4.x, so no GEOM. I wonder why all the file systems are marked dirty. The buffers are associated with specific device anyway. /S ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
In a message written on Thu, Nov 27, 2003 at 04:52:04AM +1000, Andy Farkas wrote: Matthias Andree wrote: when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. This is easy to reproduce, but apparently uninteresting to the developers: Reboot to single user, run full fsck, halt. I'll also note in my FreeBSD current debugging of some drivers it was about a 50/50 shot as to if this would happen. Having to fsck every other reboot was only made less painful by the background fsck thing. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: 5.2-BETA: giving up on 4 buffers (ata)
On Wednesday 26 November 2003 19:37, Matthias Andree wrote: Hi, when I rebooted my 5.2-BETA (kernel about 24 hours old), it gave up on flushing 4 dirty blocks. I had three UFS1 softdep file systems mounted on one ATA drive, one ext2 file system on another ATA drive and one ext2 file system on a SCSI drive. Both ext2 file systems had been mounted read-only, so they can't have had dirty blocks. At the next reboot, FreeBSD checked all three UFS file systems as they hadn't been umounted cleanly before. Makes me wonder if FreeBSD gave up on the super blocks... Same here, since about 2 weeks. I thought it was just my machine :). Best regards, Arjan pgp0.pgp Description: signature
Re: 5.2-BETA: giving up on 4 buffers (ata)
I'll also note in my FreeBSD current debugging of some drivers it was about a 50/50 shot as to if this would happen. Having to fsck every other reboot was only made less painful by the background fsck thing. Don't some BIOS' protect the superblocks as a kind of virus protection? Could this be related to them? -- Ryan leadZERO Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA: giving up on 4 buffers (ata)
Ryan Sommers wrote: I'll also note in my FreeBSD current debugging of some drivers it was about a 50/50 shot as to if this would happen. Having to fsck every other reboot was only made less painful by the background fsck thing. Don't some BIOS' protect the superblocks as a kind of virus protection? Could this be related to them? No. -DR ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
