Re: The VFS hot tracking debacle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 20/07/14 01:02, Dave Chinner wrote:
On Fri, Jul 18, 2014 at 10:25:23AM +0200, Martin Steigerwald wrote:
Am Freitag, 18. Juli 2014, 07:52:48 schrieb Dave Chinner:
On Thu, Jul 17, 2014 at 11:34:49PM +0200, Martin Steigerwald wrote:
Am Donnerstag, 17. Juli 2014, 19:35:53 schrieb Daniel Poelzleithner:
Zhi Yong Wu <zwu.kernel <at> gmail.com> writes:
Ping ^ 7
I'm following this patch now for quite some time and I have to say that
this thread+patch is one of the most disappointing experiences I had
with kernel development.

I can't understand why such a patch is simply ignored from the
maintainers
of the subsystem, no comment, no review, no checkin.
I always wanted to try this one out, but never got around doing it.

I really like the general approach of it to put the general stuff into VFS
and only the special stuff into filesystems like BTRFS.
And that's the core issue here: there are no applications that use
the information.  i.e. it's a solution looking for a problem.

I spent a lot of time reviewing and helping on this, and I made
repeated suggestions that applications like xfs_fsr could make use
of the information to do optimised file layout during
defragmentation, but nothing like that has ever been implemented.

So, really, until there is an application that actually demonstrates
the usefulness of the specific information that is tracked and
exported, we can't verify that the code as it stands is actually
useful. We can verify that the code doesn't have problems, but we
can't verify whether it is fit for purpose because it currently has
no purpose....
So this needs an example implementation for one filesystem?

I thought there is one for BTRFS.
The tracking of the "hot data" was implemented for both btrfs and
XFS. There isn't a *consumer* of that data, however, and that's the
missing piece of the picture.

Cheers,

Dave.

GFS2 has both a producer (gfs2 tracepoints) and consumer (PCP pmda) of data which is intended to provide a picture of where there are hot spots in terms of cluster locking. The hot tracking patch set sounds like it should provide something similar on a generic basis, which I think should be a useful thing to have. I did look at some earlier versions of this patch set, but I rather lost track of it - is there an uptodate git tree somewhere?

Steve.

--
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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux