On Wed, Apr 16, 2014 at 03:27:52PM -0400, Phillip Susi wrote: > On 4/16/2014 2:28 PM, Zuckerman, Boris wrote: > > [bz:] In such case I'd rather have lighter implementation of > > caching layer, than ability to track disk IOs per process. IOs per > > process can be tracked by other tools... > > What other tools? > > I can envision blktrace being extended to hook into the mm layer to > track the real source of writes, but without any overhead when the > trace is not running. How do you 'envision' this zero-overhead trace, exactly? I don't understand your high-level goal, which makes suggesting low-overhead solutions hard. Can you tolerate a certain amount of ambiguity, for example? Do you really only want to track back to the UID that is causing the I/O? With shared mmaps, are you OK attributing the I/O to one of the processes that has written to it, or do you need to attribute the write to all the processes that have written to that page? You're coming off kind of condescending, which isn't a great approach when you're asking for a new feature to be implemented. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
