On 3/4/23 17:47, Matthew Wilcox wrote:
On Sat, Mar 04, 2023 at 12:08:36PM +0100, Hannes Reinecke wrote:
We could implement a (virtual) zoned device, and expose each zone as a
block. That gives us the required large block characteristics, and with
a bit of luck we might be able to dial up to really large block sizes
like the 256M sizes on current SMR drives.
ublk might be a good starting point.
Ummmm. Is supporting 256MB block sizes really a desired goal? I suggest
that is far past the knee of the curve; if we can only write 256MB chunks
as a single entity, we're looking more at a filesystem redesign than we
are at making filesystems and the MM support 256MB size blocks.
Naa, not really. It _would_ be cool as we could get rid of all the
cludges which have nowadays re sequential writes.
And, remember, 256M is just a number someone thought to be a good
compromise. If we end up with a lower number (16M?) we might be able
to convince the powers that be to change their zone size.
Heck, with 16M block size there wouldn't be a _need_ for zones in
the first place.
But yeah, 256M is excessive. Initially I would shoot for something
like 2M.
The current work is all going towards tracking memory in larger chunks,
so writing back, eg, 64kB chunks of the file. But if 256MB is where
we're going, we need to be thinking more like a RAID device and
accumulating writes into a log that we can then blast out in a single
giant write.
Yeah. I _do_ remember someone hch-ish presenting something two years
back at ALPSS, but guess that's still on the back-burner.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
