On 2018-02-01 18:46, Edmund Nadolski wrote:
On 02/01/2018 01:12 AM, Anand Jain wrote:
On 02/01/2018 01:26 PM, Edmund Nadolski wrote:
On 1/31/18 7:36 AM, Anand Jain wrote:
On 01/31/2018 09:42 PM, Nikolay Borisov wrote:
So usually this should be functionality handled by the raid/san
controller I guess, > but given that btrfs is playing the role of a
controller here at what point are we drawing the line of not
implementing block-level functionality into the filesystem ?
Don't worry this is not invading into the block layer. How
can you even build this functionality in the block layer ?
Block layer even won't know that disks are mirrored. RAID
does or BTRFS in our case.
By block layer I guess I meant the storage driver of a particular raid
card. Because what is currently happening is re-implementing
functionality that will generally sit in the driver. So my question was
more generic and high-level - at what point do we draw the line of
implementing feature that are generally implemented in hardware devices
(be it their drivers or firmware).
Not all HW configs use RAID capable HBAs. A server connected to a SATA
JBOD using a SATA HBA without MD will relay on BTRFS to provide all
the
features and capabilities that otherwise would have provided by such a
presumable HW config.
That does sort of sound like means implementing some portion of the
HBA features/capabilities in the filesystem.
To me it seems this this could be workable at the fs level, provided it
deals just with policies and remains hardware-neutral.
Thanks. Ok.
However most
of the use cases appear to involve some hardware-dependent knowledge
or assumptions.
What happens when someone sets this on a virtual disk,
or say a (persistent) memory-backed block device?
Do you have any policy in particular ?
No, this is your proposal ;^)
You've said cases #3 thru #6 are illustrative only. However they make
assumptions about the underlying storage, and/or introduce potential for
unexpected behaviors. Plus they could end up replicating functionality
from other layers as Nikolay pointed out. Seems unlikely these would be
practical to implement.
The I/O one would actually be rather nice to have and wouldn't really be
duplicating anything (at least, not duplicating anything we consistently
run on top of). The pid-based selector works fine for cases where the
only thing on the disks is a single BTRFS filesystem. When there's more
than that, it can very easily result in highly asymmetrical load on the
disks because it doesn't account for current I/O load when picking a
copy to read. Last I checked, both MD and DM-RAID have at least the
option to use I/O load in determining where to send reads for RAID1
setups, and they do a far better job than BTRFS at balancing load in
these cases.
Case #2 seems concerning if it exposes internal,
implementation-dependent filesystem data into a de facto user-level
interface. (Do we ensure the devid is unique, and cannot get changed or
re-assigned internally to a different device, etc?)
The devid gets assigned when a device is added to a filesystem, it's a
monotonically increasing number that gets incremented for every new
device, and never changes for a given device as long as it remains in
the filesystem (it will change if you remove the device and then re-add
it). The only exception to this is that the replace command will assign
the new device the same devid that the device it is replacing had (which
I would argue leads to consistent behavior here). Given that, I think
it's sufficiently safe to use it for something like this.
--
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
