Date: Tue, 11 Aug 2009 03:42:11 -0600 From: Anthony Chavez <acc@hexadecagram.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-geom@freebsd.org Subject: Re: Re-starting a gjournal provider Message-ID: <4A813CF3.8080609@hexadecagram.org> In-Reply-To: <20090731064948.GG1584@garage.freebsd.pl> References: <4A62E0CE.1000508@hexadecagram.org> <20090729140436.GG1586@garage.freebsd.pl> <4A7289B9.2060907@hexadecagram.org> <20090731064948.GG1584@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA3D62693EA1F3256BFF3B301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > On Fri, Jul 31, 2009 at 12:05:45AM -0600, Anthony Chavez wrote: >>> It doesn't come back because something (ATA layer?) doesn't properly >>> remove ad0 provider. When you remove the disk, /dev/ad0 should disapp= ear >>> and reappear once you insert it again. >>> >>> You can still do this trick after you insert the disk again so the GE= OM >>> can schedule retaste: >>> >>> # true > /dev/ad0 >> Thank you for informing me of that trick. I tried using it after >> "gjournal stop" but unfortunately, nothing changed. >=20 > This is because it should be /dev/ad0s1 and not /dev/ad0. Try with > /dev/ad0s1. I made certain to try both devices and include the results in the example session that I included in my last post. >> Here are the points to note. >> >> 1) When I physically remove a drive from the enclosure, /dev/ad0 does >> not disappear. /dev/ad0 *always* exists until I "atacontrol detach." >> Even when the device is powered off, /dev/ad0 continues to exist. >=20 > This might be three things: >=20 > 1. Your enclosure/controller doesn't report back about disk being > removed. > > 2. Your enclosure does report back, but ATA ignores such report. > This will be a bug in ATA. >=20 > 3. Your controller doesn't support hot-swap or it supports warm-swap, > which means you have to detach it by hand before removing it. The marketing fluff at [1] claims that it does in fact support hot-swap. The extremely small (in physical size) yet extremely large (in lack of specifications) printed documentation included with the device makes absolutely no mention of whether (or not) it is capable of hot-swap. Are there any tools available that would enable me to determine whether or not it supports hot-/warm-swap? All of the places I've looked (/var/log/messages, usbdevs, lspci, gnome-device-manager) seem to be devoid of any such information. >> 2) /dev/ad0s1.journal disappears when I "gjournal stop." >> /dev/ad0s1.journal is the device that, AFAIK, will only come back afte= r >> "atacontrol detach ata0; atacontrol attach ata0". >=20 > It should also get back after 'true > /dev/ad0s1'. What this command do= > is to open provider for writing (it doesn't write anything). In GEOM it= > will trigger spoil event and then, once command completes, it will > trigger retaste event. This mean that GEOM will inform gjournal to chec= k > /dev/ad0s1 again and this will allow gjournal to find its metadata and > create /dev/ad0s1.journal once again. I understand, but that is not happening. > One more test would be in place. If you could try the command below > before removing disk and after inserting different disk: >=20 > # diskinfo -v /dev/ad0 >=20 > If it shows exactly the same in two cases, it means that it is not awar= e > that disk was replaced and detach/attach cycle is needed. Okay, I attempted that. The data displayed was exactly the same. I also attempted to power off the device before removing the first drive and power it back on when inserting the new one. The data displayed was exactly the same in that case also. >> 1) Is "atacontrol detach ata0 && atacontrol attach ata0" in fact a saf= e >> operation to perform in any circumstance? >> >> My better judgment has me thinking that the answer to this question is= >> almost certainly "no." However, I am hypothesizing that it would safe= >> enough if all devices on ata0 are properly unmounted first, but if I c= an >> avoid that, I will. It feels clumsy and seems to defeat the purpose o= f >> hot-swapping. >=20 > It should be safe, but there were plenty of bugs related to disappearin= g > disk from under mount file system, etc. If nothing is mounted you shoul= d > be fine (if there are no ATA bugs in this area). >=20 > But for full hot-swap the disk controller should discover disk being > removed and ATA code should remove it from /dev/. It would seem that unless I'm encountering an ATA bug, I am the victim of false advertising, then. I'm not terribly surprised though, to be honest. I don't really think that the device was designed to be used in this manner. It's not terribly sophisticated. ;-) >> 2) Is it *necessary* to "gjournal stop" before hot-swapping? >> >> In such a scenario, I would opt to simply "umount; gjournal sync," swa= p >> disks, and then "atacontrol cap ad0; mount" (or even just "mount"). I= t >> seems quite likely, however, that all drives that undergo this treatme= nt >> would be *required* to have gjournal labels since /dev/ad0s1.journal >> would never disappear (although I've yet to actually test that). >=20 > I'd go with 'umount; gjournal stop' and drop 'gjournal sync'. >=20 > Controler should inform ATA that disk is gone. ATA should inform GEOM > that ad0 is gone. If that would be the case, simple 'umount; gjournal > sync' will be enough. But because it isn't the case, you have to stop > gjournal and detach ad0. Okay so I am skipping "gjournal sync" only for this particular circumstance, then. Under ideal circumstances, I shouldn't have to "gjournal stop," then? >> 3) If the answer to question 2 is "yes," then how can I handle the cas= e >> of inserting a drive that does *not* have a gjournal label? >=20 > There's nothing special here. Let's see how diskinfo test will go first= =2E Okay, since the 2 diskinfo's were identical, what then? It seems to me that a properly working hot-swap device would report the correct information to GEOM, which would create /dev/*.journal devices as necessary, is that correct? >> 1) Is it really necessary to perform 3 "sync" commands before "umount"= ? >> >> Line 94 of src/sbin/umount/umount.c,v 1.45.20.1 has me thinking that t= he >> answer is "no," since it calls sync() itself, albeit only once. I got= >> the idea for executing "sync" three times from /etc/rc.suspend. >=20 > The idea is that unmount should take case of syncing data. There should= > be not need for even one sync. It is called "just in case". My experience in the past is that a simple umount has been sufficient, but since gjournal is still new territory for me, I thought I had better make sure. Thank you. ;-) --=20 Anthony Chavez http://hexadecagram.org/ mailto:acc@hexadecagram.org xmpp:acc@hexadecagram.org --------------enigA3D62693EA1F3256BFF3B301 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqBPPgACgkQbZTbIaRBRXHzhgCfY7/hry78dXVwQed5JrB2oend fEEAn2Ckmkpi9HcDzBShaLyU1PdCYsFT =OvRN -----END PGP SIGNATURE----- --------------enigA3D62693EA1F3256BFF3B301--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A813CF3.8080609>