Re: [PATCH 09/10] libfrog: improve ramdisk handling in platform_flush_device

["Darrick J. Wong" <djwong@kernel.org>]

On Sat, Sep 26, 2026 at 08:02:54AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 25, 2026 at 03:47:20PM -0700, Darrick J. Wong wrote:
> > > +	 * Historically the ram disk driver destroyed all data when BLKFLSBUF
> > > +	 * was called.  That has been fixed a long time, but still be careful.
> > > +	 */
> > > +	if (S_ISBLK(st.st_mode) && major(st.st_rdev) != RAMDISK_MAJOR)
> > >  		return ioctl(fd, BLKFLSBUF, 0);
> > 
> > BLKFLSBUF support on ramdisks hasn't been in the kernel since commit
> > ff26956875c2f0 ("brd: remove support for BLKFLSBUF") which was merged in
> > 4.10 in late 2016.  Maybe we should remove it?
> 
> People use xfsprogs on really old kernels.  Now no one really should
> care about data integrity on a ramdisk, but there's not too much downside
> of just keeping it, so I'd rather leave it alone.
> 
> The real question to be is why we even bother with BLKFLSBUF at all.
> It seems to come from e2fsprogs, where that is optionally called from
> ext2fs_sync_device with a a comment:
> 
> 	... and optionally attempt to
> 	flush the buffer cache.  The latter is basically only useful for
> 	system benchmarks and for torturing systems in burn-in tests.  :)
> 
> but despite that comment, all caller do set that flag.
> 
> btrfsprogs and f2fs-tool do not have any calls to BLKFLSBUF.

Yeah, I don't see much point in invalidating the bdev buffer cache after
flushing its contents to disk.

--D