[PATCHv10 9/9] scsi: set permanent stream count in block limits
Keith Busch
kbusch at kernel.org
Fri Nov 1 07:49:12 PDT 2024
On Fri, Nov 01, 2024 at 08:16:30AM +0100, Hans Holmberg wrote:
> On Thu, Oct 31, 2024 at 3:06 PM Keith Busch <kbusch at kernel.org> wrote:
> > On Thu, Oct 31, 2024 at 09:19:51AM +0100, Hans Holmberg wrote:
> > > No. The meta data IO is just 0.1% of all writes, so that we use a
> > > separate device for that in the benchmark really does not matter.
> >
> > It's very little spatially, but they overwrite differently than other
> > data, creating many small holes in large erase blocks.
>
> I don't really get how this could influence anything significantly.(If at all).
Fill your filesystem to near capacity, then continue using it for a few
months. While the filesystem will report some available space, there
may not be many good blocks available to erase. Maybe.
> > Again, I absolutely disagree that this locks anyone in to anything.
> > That's an overly dramatic excuse.
>
> Locking in or not, to constructively move things forward (if we are
> now stuck on how to wire up fs support)
But we're not stuck on how to wire up to fs. That part was settled and
in kernel 10 years ago. We're stuck on wiring it down to the driver,
which should have been the easiest part.
> I believe it would be worthwhile to prototype active fdp data
> placement in xfs and evaluate it. Happy to help out with that.
When are we allowed to conclude evaluation? We have benefits my
customers want on well tested kernels, and wish to proceed now.
I'm not discouraing anyone from continuing further prototypes,
innovations, and improvements. I'd like to spend more time doing that
too, and merging something incrementally better doesn't prevent anyone
from doing that.
> Fdp and zns are different beasts, so I don't expect the results in the
> presentation to be directly translatable but we can see what we can
> do.
>
> Is RocksDB the only file system user at the moment?
Rocks is the only open source one I know about. There are propietary
users, too.
More information about the Linux-nvme
mailing list