From owner-freebsd-arm@freebsd.org Thu Dec 14 21:58:47 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 745DFE912C2 for ; Thu, 14 Dec 2017 21:58:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 368047B641 for ; Thu, 14 Dec 2017 21:58:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23661 invoked from network); 14 Dec 2017 21:58:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 14 Dec 2017 21:58:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 14 Dec 2017 16:58:40 -0500 (EST) Received: (qmail 26951 invoked from network); 14 Dec 2017 21:58:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Dec 2017 21:58:40 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F61FEC956A; Thu, 14 Dec 2017 13:58:39 -0800 (PST) From: Mark Millard Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Filesystem full, but df says not. Date: Thu, 14 Dec 2017 13:58:38 -0800 In-Reply-To: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> Cc: bob prohaska , freebsd-arm@freebsd.org To: "Rodney W. Grimes" References: <201712142056.vBEKupPm098816@pdx.rh.CN85.dnsmgr.net> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:58:47 -0000 On 2017-Dec-14, at 12:56 PM, Rodney W. Grimes wrote: >>> On 2017-Dec-14, at 11:00 AM, bob prohaska = 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