Date: Thu, 14 Dec 2017 13:58:38 -0800 From: Mark Millard <markmi@dsl-only.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: Filesystem full, but df says not. Message-ID: <EAB18AF7-6413-4739-B3F0-87B85DE398DE@dsl-only.net> In-Reply-To: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> References: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Dec-14, at 12:56 PM, Rodney W. Grimes <freebsd-rwg at = pdx.rh.CN85.dnsmgr.net> wrote: >>> On 2017-Dec-14, at 11:00 AM, bob prohaska <fbsd at www.zefox.net> = wrote: >>>=20 >>>=20 >>>> An rpi2 running -current reported errors during boot like this on = the >>>> serial console after a graceful reboot: >>>>=20 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 3, cgp: = 0x58e2c1f5 !=3D bp: 0x903c297 >>>> UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 0, cgp: = 0x4c0a5f41 !=3D bp: 0x38b82866 >>>=20 >>> Believe the above low-level messages. >>=20 >> And be aware that when a cg checksum fails that CG's freespace is no >> longer avaliable to be used until the CG checksum has been corrected >> by a fsck. >>=20 >> You are probably moving your file system accross the "has CG = checksum" >> and "does not have CG checksum" boundary and when you do that your >> older kernel does not write the checksum and your newer kernel gets >> upset about that. >>=20 >>=20 >>>> /: write failed, filesystem is full >>>> cp: /etc/motd: No space left on device >>=20 >> This error is correct, as the free space in your CG is not avaliable = as >> that CG has failed chksum.=20 I see. Just not how I took the phrase "filesystem is full". Now the file system can be full when df shows space available. That will tend to seem odd to folks. >>>=20 >>> My guess: >>>=20 >>> Other places likely translate the more detailed error >>> classification to more generic classifications that >>> hopefully result in an appropriate handling of the issue >>> but is otherwise not necessarily correct. >>=20 >> It is correct as stated, for the reasons I state. >>=20 >>>=20 >>> In other words: do not believe the later related messages >>> in all its detail. >>=20 >> Oh believe it! Sorry for the misinterpretation. >> . >> Mounting late filesystems:. >> Dec 14 10:08:56 www kernel: pid 1394 (cp), uid 0 inumber 53912 on /: = filesystem full >>=20 >> Root is on the microSD card, /usr /var /tmp and swap are on usb = flash. >>=20 >> Nevertheless, it reached multi-user and allowed me to ssh in and = run df, >> which reported >> Filesystem 1K-blocks Used Avail Capacity Mounted = on >> /dev/ufs/rootfs 1473116 479936 875332 35% / >> devfs 1 1 0 100% /dev >> /dev/msdosfs/MSDOSBOOT 51140 7588 43552 15% = /boot/msdos >> /dev/da0e 52221244 28697844 19345704 60% /usr >> /dev/da0d 3044988 517860 2283532 18% /tmp >> /dev/da0a 2031132 122868 1745776 7% /var The above sort of result becomes the odd thing for people to understand the classification. > This activity probably did not depend on the bad cylinder > checksums. >=20 >> Still, any activity that wrote to disk repeated the filesystem full = error. >>=20 >> This happened with three different kernels, dating Dec 12, 7 and Aug = 26. >> Running fsck -fy once in single user didn't seem to help, although it=20= >> finished without obvious errors. Running fsck -fy repeatedly in = single-user=20 >> seems to have cleared the error, but it's a surprising development. >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EAB18AF7-6413-4739-B3F0-87B85DE398DE>