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
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 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 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)
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]"
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)
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)
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)
"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 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)
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)
> 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]"