On 12/16/2014 01:05 AM, Hugo Mills wrote:
On Mon, Dec 15, 2014 at 07:47:06PM -0800, Robert White wrote:
I prefer "slice", not that I am totally happy with that word either.
But by the time you get through loopback devices, memory map
devices, the "device files" that represent parts of "partitioned"
devices, logical "volumes", and god only knows what future
"thingies" we will end up dealing with... I like the terms that
remove false hints.
All this agreed, but "slice" will be largely viewed as a neologism
by anyone who hasn't used (IIRC) BSD or Solaris. On the other hand,
for all their other flaws, "device" is much better than "disk" here,
as you could he talking about a partition, a flash memory card (which
many people don't view as "disks"), or a network block device. You
could refer to a "block device" to clarify, because that's really what
we're talking about here, but it could get a bit cumbersome.
That's part of why I'm not perfectly happy with slice either.
But just last week I was trying to explain the whole thing of being out
of raw space to allocate storage extents compared to being out of
managed space to allocate file, um, extents...
And I'm currently going around in circles over whole "when is a sector
free" as far as /bin/df is concerned...
we've got devices as we view them which are parts of devices as the ...
We've got storage extents and we are dealing with people who are used to
seeing "extent" used as the name of contiguously stored sections of
files, but our extents store segments of the devices.
We've also got those two-disk raid-5(s) which we've established are
mathematically correct, but which will trip up everyone that is used to
the three-or-more rule.
Then using the variable bytenr instead of byte_number (when all the rest
of the variables are spelled out) and I'm not sure if thats in the
logical view or the physical layout view, or both.
In short (too late) there is a huge lexicon problem to newcomers here
because of noun-overloading (in the programmatic sense).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
