The commit 607d432d referred a static int array defined in ctree.h,
and a static inline function (btrfs_super_csum_size) using this array,
the obvious problem is every c file using that function would have a
local copy of that int array, multiple c files calling would result
multiple copies of that
From: Ben Chociej
Add support for the new hot data functionality in-kernel. Three ioctls
were added to export hot data statistics and turn hot data tracking on
and off per inode. This patch enables btrfsctl to interact with those
ioctls.
Signed-off-by: Ben Chociej
Signed-off-by: Matt Lupfer
Te
From: Ben Chociej
Modified mkfs.btrfs to add hot data relocation option (-h) which
preallocates BTRFS_BLOCK_GROUP_DATA_SSD and
BTRFS_BLOCK_GROUP_METADATA_SSD at mkfs time for future use by hot data
relocation code. Also added a userspace function to detect whether a
block device is an SSD by rea
This patch set introduces functionality into btrfsctl and mkfs.btrfs to
support the kernel patches for hot data tracking and migration to SSD
with Btrfs. New functionality includes a -h option to mkfs.btrfs to
preallocate approrpiate block group types for SSD data migration, and
also includes addit
From: Ben Chociej
The relocation code operates on the heat hash lists to identify hot or
cold data logical file ranges that are candidates for relocation. The
triggering mechanism for relocation is controlled by a global heat
threshold integer value (fs_root->heat_threshold). Ranges are queued fo
From: Ben Chociej
BTRFS_IOC_GET_HEAT_INFO: return a struct containing the various
metrics collected in btrfs_freq_data structs, and also return a
calculated data temperature based on those metrics. Optionally, retrieve
the temperature from the hot data hash list instead of recalculating it.
BTRF
From: Ben Chociej
Add a /sys/kernel/debug/btrfs_data// directory for each
volume that contains two files. The first, `inode_data', contains the
heat information for inodes that have been brought into the hot data map
structures. The second, `range_data', contains similar information for
subfile r
From: Ben Chociej
Adds hot_inode_tree and hot_range_tree structs to keep track of
frequently accessed files and ranges within files. Trees contain
hot_{inode,range}_items representing those files and ranges, each of
which contains a btrfs_freq_data struct with its frequency of access
metrics (num
From: Ben Chociej
Miscellaneous features that implement hot data tracking, enable hot data
migration to faster media, and generally make the hot data functions a
bit more friendly.
ctree.h: Add the root hot_inode_tree and heat hashlists. Defines some
mount options and inode flags for turning all
From: Ben Chociej
Adds a hash table structure to efficiently lookup the data temperature
of a file. Also adds a function to calculate that temperature based on
some metrics kept in custom frequency data structs (in the next patch).
Signed-off-by: Ben Chociej
Signed-off-by: Matt Lupfer
Signed-o
These patches are a replacement for our previous hot data tracking
patches. They include some bugfixes as well as the previously promised
hot data relocation code for moving frequently accessed data to SSD.
Structurally, the patches are quite similar to the first set, with the
notable addition of n
On Aug 12, 2010, at 12:57 PM, "K. Richard Pixley" wrote:
> On 8/12/10 10:46 , C Anthony Risinger wrote:
>> On Aug 12, 2010, at 10:58 AM, "K. Richard Pixley"
>> wrote:
>>> And should I be worried about what umount -l might be leaving
>>> behind? (eg, any unfreed kernel resources) Or is that a re
On 8/12/10 10:46 , C Anthony Risinger wrote:
On Aug 12, 2010, at 10:58 AM, "K. Richard Pixley" wrote:
And should I be worried about what umount -l might be leaving
behind? (eg, any unfreed kernel resources) Or is that a reasonable
way to deal with this situation on an ongoing basis?
On 8/12
On Aug 12, 2010, at 10:58 AM, "K. Richard Pixley" wrote:
> And should I be worried about what umount -l might be leaving
> behind? (eg, any unfreed kernel resources) Or is that a reasonable
> way to deal with this situation on an ongoing basis?
>
> --rich
>
> On 8/12/10 08:55 , K. Richard Pixle
And should I be worried about what umount -l might be leaving behind?
(eg, any unfreed kernel resources) Or is that a reasonable way to deal
with this situation on an ongoing basis?
--rich
On 8/12/10 08:55 , K. Richard Pixley wrote:
I'm running into a situation where I can't unmount a moun
I'm running into a situation where I can't unmount a mounted
snapshot. It shows "busy" even though neither lsof nor fuser show any
open files. Umount -f doesn't work although umount -l does.
Is there anything else I can do to debug this scenario or to clear the
busy status myself? Or am I
On Thu, Aug 12, 2010 at 08:46:54AM +0800, Cheng Renquan wrote:
> commit 607d432d referred a static int array defined in a header file,
> and a static inline function (btrfs_super_csum_size) using this array,
> the obvious result is every c file using that function would have
> a local copy of that
On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
wrote:
> Hi,
>
> I am using a btrfs filesystem created with raid0 for data and metadata
> for (temporary) storage of tv recordings from my vdr. The filesystem was
> created under kernel version 2.6.34. An initial btrfs balance command
> succeeded. S
Hi,
I am using a btrfs filesystem created with raid0 for data and metadata
for (temporary) storage of tv recordings from my vdr. The filesystem was
created under kernel version 2.6.34. An initial btrfs balance command
succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no
longer fin
19 matches
Mail list logo
