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
On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
philipp.andr...@gmail.com 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
On Aug 12, 2010, at 10:58 AM, K. Richard Pixley r...@noir.com 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
On 8/12/10 10:46 , C Anthony Risinger wrote:
On Aug 12, 2010, at 10:58 AM, K. Richard Pixleyr...@noir.com 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
From: Ben Chociej bchoc...@gmail.com
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 bchoc...@gmail.com
From: Ben Chociej bchoc...@gmail.com
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
From: Ben Chociej bchoc...@gmail.com
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
From: Ben Chociej bchoc...@gmail.com
Add a /sys/kernel/debug/btrfs_data/device_name/ 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
From: Ben Chociej bchoc...@gmail.com
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).
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
From: Ben Chociej bchoc...@gmail.com
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
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
12 matches
Mail list logo
