On Thu, Jun 15, 2023 at 2:14 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > Well, if there was, say, a call for pre-release testing, > > Well, Debian did ask for testing. > > I guess I should explicitly tell debian-hurd@ "hey that's a matter for > *us* too".
I don't think I understand what you mean; but what I mean is: if like a month before the release you (or someone) would have posted to bug-hurd, saying: "hey folks, we're going to do the next Debian release in a month, here's an image that is very close to what we're going to release, please test it", I'd have reported this a month ago, and we'd have plenty of time to fix or work around this and avoid the PR disaster. Then maybe there'd be another call for testing once the final image is formed, if only to add any known issues to release notes ("using > 80 GB disk images is known to be broken with qcow2 and vdi formats"). > > So the installed system is not to blame, it must be that the installer > > is corrupting the FS somehow. > > Possibly some missing disk cache flush. I believe we have done fixes > there in the past, but possibly some things are still missing... Hmm, I might be looking in the wrong places for it, but where does disk flushing happen at all? What I can see from looking through the source is: sync(1) or whatever -> fsys_syncfs -> diskfs_sync_everything -> pager_sync -> file_pager_write_page -> pending_blocks_write -> store_write -> device_write -> (*dev->emul_ops->write) -> (*bd->ds->fops->write) -> block_write But what syncs / flushes the Linux IDE device? Related question: does the Mach device API even include provisions for flushing? -- I don't see any. > Or perhaps. (truncated message?) Sergey