Date: Sun, 03 Feb 2019 22:49:52 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 235473] gconcat online append Message-ID: <bug-235473-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235473 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: bugs@FreeBSD.org Reporter: noah.bergbauer@tum.de Created attachment 201701 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D201701&action= =3Dedit Initial patch draft It really shouldn't be necessary to rebuild a gconcat volume from scratch j= ust to add another disk. This is particularly inconvenient because it forces on= e to remount/restart any filesystems/geoms stacked on top of gconcat for no appa= rent 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 s= olve 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 did= n'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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235473-227>