Hot data Tracking
What happened to the hot data tracking feature in btrfs? There are a lot of old patches from aug 2010, but it looks like the feature has been completly removed from the current version of btrfs. Is this feature still on the roadmap?
Quoted 4 lines · Timo Witte
What happened to the hot data tracking feature in btrfs? There are a lot of old patches from aug 2010, but it looks like the feature has been completly removed from the current version of btrfs. Is this feature still on the roadmap?
Removed? AFAIK it hasn't been ever merged, though it's be a nice feature. There were suggestions to turn it into a generic API for any filesystem to use, but this hasn't happened.
The patches are quite independent and it was easy to refresh them on top of current for-linus branch. A test run did not survive a "random" xfstest, 013 this time, so I probably mismerged some bits. The patchset lives in branch foreign/ibm/hotdatatrack in my git repo.
david
Quoted 9 lines · David Sterba
Quoted 4 lines · Timo Witte
What happened to the hot data tracking feature in btrfs? There are a lot of old patches from aug 2010, but it looks like the feature has been completly removed from the current version of btrfs. Is this feature still on the roadmap?
Removed? AFAIK it hasn't been ever merged, though it's be a nice feature. There were suggestions to turn it into a generic API for any filesystem to use, but this hasn't happened.
Quoted 8 lines
The patches are quite independent and it was easy to refresh them on top of current for-linus branch. A test run did not survive a "random" xfstest, 013 this time, so I probably mismerged some bits. The patchset lives in branch foreign/ibm/hotdatatrack in my git repo.
david
Someone recently mentioned bcache in another post who seems to cover this subject fairly well. However would it not make sense if btrfs actually was able to automatically take advantage of whatever disks is added to the pool? For example if you have 10 disk of different size and performance in a raid5/6 like configuration would it not be feasible if btrfs automagically (option) could manage it's own cache? For example it could reserve a chunk of free space as cache (based on how much data is free) and stripe data over all disks (cache). When the filesystem becomes idle or at set intervals it could empty the cache or move/rebalance pending writes over to the original raid5/6 like setup. As far as I remember hot data tracking was all about moving the data over to the fastest disk. Why not utilize all disks and benefit from disks working together?
Svein Engelsgjerd
Quoted 3 lines · On Thursday 03 of May 2012 15:09:25 Waxhead wrote:
Quoted 2 lines · David Sterba
Quoted 1 line · Timo Witte
What happened to the hot data tracking feature in btrfs? There are=
a lot
Quoted 1 line
Quoted 1 line
Quoted 1 line
of old patches from aug 2010, but it looks like the feature has be=
en
Quoted 1 line
Quoted 1 line
Quoted 1 line
completly removed from the current version of btrfs. Is this featu=
re
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
still on the roadmap?
=20
Removed? AFAIK it hasn't been ever merged, though it's be a nice feature. There were suggestions to turn it into a generic API for a=
ny
Quoted 3 lines
Quoted 3 lines
filesystem to use, but this hasn't happened.
=20
The patches are quite independent and it was easy to refresh them o=
n top
Quoted 2 lines
Quoted 2 lines
of current for-linus branch. A test run did not survive a "random" xfstest, 013 this time, so I probably mismerged some bits. The patc=
hset
Quoted 7 lines
Quoted 4 lines
lives in branch foreign/ibm/hotdatatrack in my git repo. =20
=20
david=20
Someone recently mentioned bcache in another post who seems to cover this subject fairly well.
bcache does one very specific assertion that isn't met by btrfs: overwr= ing old=20
data in a file writes data to the same place on the disk, same goes for= =20
metadata. In other words, it won't work with COW file system.
Quoted 2 lines
However would it not make sense if btrfs
actually was able to automatically take advantage of whatever disks i=
s
Quoted 1 line
added to the pool? For example if you have 10 disk of different size =
and
Quoted 1 line
performance in a raid5/6 like configuration would it not be feasible =
if
Quoted 1 line
btrfs automagically (option) could manage it's own cache? For example=
it
Quoted 1 line
could reserve a chunk of free space as cache (based on how much data =
is
Quoted 3 lines
free) and stripe data over all disks (cache). When the filesystem becomes idle or at set intervals it could empty the cache or move/rebalance pending writes over to the original raid5/6 like setup=
=2E
Quoted 3 lines
As far as I remember hot data tracking was all about moving the data over to the fastest disk. Why not utilize all disks and benefit from disks working together?
=46or this to work, you need feature set that allows hot data movement = between=20
disks and data restriping. Then such cache feature will use much of the=
same=20
code.
Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html