Re: Btrfs Heatmap - v3 - scriptable .. more flexible

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

 



Rereading this...

On 12/19/2016 12:53 AM, Hans van Kranenburg wrote:
> [...]
> 
> Qu Wenruo pointed out that the greyscale value used for dev_extent (the
> usage for the block group is used here) does not necessarily have to be
> correct: "And for 50%/50% assumption for RAID0, it's not true and we can
> easily create a case where it's 100%/0%". (Qu)
> 
> I replied on that with "OTOH, for most cases it will still be correct
> enough for the eye, because statistically seen, distribution of data
> over the stripes will be more uniform more often than not".
> 
> Still, "The point is, for full fs or per-device output, a developer may
> focus on the fragments of unallocated space in each device." (Qu)

What does "unallocated" mean here?

I always use "unallocated" for space that is not part of a
dev_extent/chunk/blockgroup at all, and "unused" for free space inside
allocated space.

> The last commit, "Don't hardcode minimal brightness for dev_extents"
> exposes the min_brightness, which tunes the brightness range of
> allocated space. "Setting it to 255 will cause any allocated space to
> show up as bright white, regardless of usage."

If meant as unused free space in allocated dev_extent space, then this
does not help much of course.

OTOH, I don't think the information of data distribution over
dev_extents belonging to a single blockgroup is available at all, when
walking the IOCTL paths.

-- 
Hans van Kranenburg
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux