https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235473
Bug ID: 235473
Summary: gconcat online append
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: noah.bergba...@tum.de
Created attachment 201701
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201701&action=edit
Initial patch draft
It really shouldn't be necessary to rebuild a gconcat volume from scratch just
to add another disk. This is particularly inconvenient because it forces one to
remount/restart any filesystems/geoms stacked on top of gconcat for no apparent
reason.
I attached my first attempt at hacking on this. It works! But since I have
never worked with geoms (or rather any part of the kernel at all) before I am
very unsure about correctness, especially when it comes to locking and race
conditions in general.
Since the existing mutex appears to have a very specific purpose, I created a
new one. One obvious race is keeping the `g_access` levels in sync, so I'm
locking over there as well. I would like to avoid locking a mutex in the
regular IO path (g_concat_start) as this looks like a performance footgun to
me, but given that I have to do array reallocation it seems to me that the only
alternative is to leak memory - perhaps an rwlock would be appropriate to solve
this?
Even after using FreeBSD for several years I never understood the hardcode
option so I didn't implement that either. Incrementing G_CONCAT_VERSION didn't
work for some reason (userland tool wouldn't pick up the new version), did I
miss something? Also I still need to update the manpage.
I mean, the patch is quite literally a copy-pasted mix from gmultipath
(resize/insert capability), gmirror (metadata update) and gconcat itself. It
works but it really needs someone who actually knows how this stuff works to
advise me on how to proceed.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
