Quotes of the week

[Posted August 3, 2016 by corbet]

I've been saying this from the start: we can't make use of all the capabilities of pmem [persistent memory] with existing filesystems and DAX. DAX is supposed to be a *stopgap measure* until pmem native solutions are built and mature. Finding limitations like the above only serve to highlight the fact DAX on ext4/XFS is only a partial solution.

The real problem is, as always, a lack of resources to implement everything we want to be able to do. Building a new filesystem is hard, takes a long time, and all the people we have that might be able to do it are fully occupied by maintaining and enhancing the existing Linux filesystems to support things like DAX or other functionality that users want (e.g. rmap, reflink, copy offload, etc).

— Dave Chinner

ABIs increase the utility of the kernel.

— Ingo Molnar

Quotes of the week

Posted Aug 4, 2016 4:06 UTC (Thu) by djbw (subscriber, #78104) [Link]

DAX was not designed to accelerate XFS. DAX was designed to give applications a kernel-bypass path to byte-addressable persistent memory.

Quotes of the week

Posted Aug 4, 2016 13:06 UTC (Thu) by Paf (subscriber, #91811) [Link] (2 responses)

That comment to which Ingo is replying is pretty stunning. I get the idea - not having them maintains flexibility - but that's basically an argument against ever having them. It basically says "but someone might use them!"... In which case then perhaps they are valuable...?

Quotes of the week

Posted Aug 4, 2016 18:28 UTC (Thu) by micka (subscriber, #38720) [Link] (1 responses)

In the same thread:

>Damn right. Somebody wants to use those as private debugging patches -
sure, that's what the mechanism is good for. Just keep them in your
test builds, where *you* will be responsible for keeping them working, etc.

I think that a pretty sensible point of view.

VFS tracepoints are not just for debugging

Posted Aug 4, 2016 23:01 UTC (Thu) by bnorris (subscriber, #92090) [Link]

It's not for debugging; it's for boot time optimization. See the initial research done here:

https://code.google.com/archive/p/prefetch/
http://prefetch.googlecode.com/files/gsoc-prefetching-pre...

AFAICT, this work yielded Ubuntu's ureadahead implementation. Notably, that's been replaced by systemd-readahead, and then systemd dropped it recently due to the prevalence of SSDs (this was more useful for spinning HDDs). It's still in use on Chrome OS (which still utilizes its own fork of Upstart), and Google still carries the mentioned patch in their downstream Chrome OS kernel.

So, this feature most certainly *was* useful for real, non-debug systems. Its current utility is probably recently diminished though.

Disclaimer: I work on Chrome OS. And in fact, this very patch has annoyed me during debugging with the trace event infrastructure, since ureadahead polluted my trace log with a bunch of VFS syscalls. But hey, that's how I learned about this feature!