<div dir="ltr">I did find in /etc/fstab entries like this for those 10 disks<div><br></div><div>/dev/sdh1   /var/lib/ceph/osd/ceph-60  xfs noatime,nodiratime 0 0</div><div><br></div><div>Should I comment all 10 of them out (for osd.{60-69}) and try rebooting again?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 5, 2018 at 11:54 AM, Hayashida, Mami <span dir="ltr"><<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was just going to write that the "ln" command did not solve the problem.  When I rebooted the node, it again went into an emergency mode and I got exactly the same errors (<span style="font-size:12.8px">systemd[1]: Timed out waiting for device dev-sdh1.device.;</span><span style="font-size:12.8px">-- Subject: Unit dev-sdh1.device has failed...).  I will look into /etc/ftab to see what I find there.  </span></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Nov 5, 2018 at 11:51 AM, Hector Martin <span dir="ltr"><<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Those units don't get triggered out of nowhere, there has to be a<br>
partition table with magic GUIDs or a fstab or something to cause them<br>
to be triggered. The better way should be to get rid of that instead of<br>
overriding the ceph-disk service instances, I think.<br>
<br>
Given dev-sdh1.device is trying to start, I suspect you have them in<br>
/etc/fstab. You should have a look around /etc to see if you have any<br>
stray references to those devices or old ceph-disk OSDs.<br>
<span><br>
On 11/6/18 1:37 AM, Hayashida, Mami wrote:<br>
> Alright.  Thanks -- I will try this now.<br>
> <br>
> On Mon, Nov 5, 2018 at 11:36 AM, Alfredo Deza <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a><br>
</span><span>> <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
> <br>
>     On Mon, Nov 5, 2018 at 11:33 AM Hayashida, Mami<br>
</span><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     ><br>
>     > But I still have 50 other Filestore OSDs on the same node, though.  Wouldn't doing it all at once (by not identifying the osd-id) be a problem for those?  I have not migrated data out of those 50 OSDs yet.<br>
> <br>
>     Sure, like I said, if you want to do them one by one, then your<br>
>     initial command is fine.<br>
> <br>
>     ><br>
>     > On Mon, Nov 5, 2018 at 11:31 AM, Alfredo Deza <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a><br>
</span><span>>     <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
>     >><br>
>     >> On Mon, Nov 5, 2018 at 11:24 AM Hayashida, Mami<br>
</span><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> ><br>
>     >> > Thank you for all of your replies. Just to clarify...<br>
>     >> ><br>
>     >> > 1. Hector:  I did unmount the file system if what you meant was<br>
>     unmounting the /var/lib/ceph/osd/ceph-$osd-id<wbr>   for those disks (in<br>
>     my case osd.60-69) before running the ceph-volume lvm zap command<br>
>     >> ><br>
>     >> > 2. Alfredo: so I can at this point run the "ln" command<br>
>     (basically getting rid of the symbolic link) for each of those OSDs<br>
>     I have converted?  For example<br>
>     >> ><br>
>     >> > ln -sf /dev/null /etc/systemc/system/ceph-disk@<wbr>60.service<br>
>     >> That will take care of OSD 60. This is fine if you want to do<br>
>     them one<br>
>     >> by one. To affect everything from ceph-disk, you would need to:<br>
>     >><br>
>     >> ln -sf /dev/null /etc/systemd/system/ceph-disk@<wbr>.service<br>
>     >><br>
>     >> ><br>
>     >> >    Then reboot?<br>
>     >> ><br>
>     >> ><br>
>     >> > On Mon, Nov 5, 2018 at 11:17 AM, Alfredo Deza <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a><br>
</span><span>>     <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
>     >> >><br>
>     >> >> On Mon, Nov 5, 2018 at 10:43 AM Hayashida, Mami<br>
</span><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> >> ><br>
>     >> >> > Additional info -- I know that<br>
>     /var/lib/ceph/osd/ceph-{60..6<wbr>9} are not mounted at this point (i.e. <br>
>     mount | grep ceph-60, and 61-69, returns nothing.).  They don't show<br>
>     up when I run "df", either.<br>
>     >> >> ><br>
>     >> >> > On Mon, Nov 5, 2018 at 10:15 AM, Hayashida, Mami<br>
</span><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> >> >><br>
>     >> >> >> Well, over the weekend the whole server went down and is<br>
>     now in the emergency mode. (I am running Ubuntu 16.04).  When I run<br>
>     "journalctl  -p err -xb"   I see that<br>
>     >> >> >><br>
>     >> >> >> systemd[1]: Timed out waiting for device dev-sdh1.device.<br>
>     >> >> >> -- Subject: Unit dev-sdh1.device has failed<br>
>     >> >> >> -- Defined-By: systemd<br>
>     >> >> >> -- Support: <a href="http://lists.freeddesktop.org/" rel="noreferrer" target="_blank">http://lists.freeddesktop.org/</a><wbr>..<br>
</span>>     <<a href="http://lists.freeddesktop.org/." rel="noreferrer" target="_blank">http://lists.freeddesktop.or<wbr>g/.</a>.>..<br>
<span>>     >> >> >> --<br>
>     >> >> >> -- Unit dev-sdh1.device has failed.<br>
>     >> >> >><br>
>     >> >> >><br>
>     >> >> >> I see this for every single one of the newly-converted<br>
>     Bluestore OSD disks (/dev/sd{h..q}1).<br>
>     >> >><br>
>     >> >> This will happen with stale ceph-disk systemd units. You can<br>
>     disable those with:<br>
>     >> >><br>
>     >> >> ln -sf /dev/null /etc/systemd/system/ceph-disk@<wbr>.service<br>
>     >> >><br>
>     >> >><br>
>     >> >> >><br>
>     >> >> >><br>
>     >> >> >> --<br>
>     >> >> >><br>
>     >> >> >> On Mon, Nov 5, 2018 at 9:57 AM, Alfredo Deza<br>
</span><span>>     <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a> <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
>     >> >> >>><br>
>     >> >> >>> On Fri, Nov 2, 2018 at 5:04 PM Hayashida, Mami<br>
</span><div><div>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> >> >>> ><br>
>     >> >> >>> > I followed all the steps Hector suggested, and almost<br>
>     everything seems to have worked fine.  I say "almost" because one<br>
>     out of the 10 osds I was migrating could not be activated even<br>
>     though everything up to that point worked just as well for that osd<br>
>     as the other ones. Here is the output for that particular failure:<br>
>     >> >> >>> ><br>
>     >> >> >>> > *****<br>
>     >> >> >>> > ceph-volume lvm activate --all<br>
>     >> >> >>> > ...<br>
>     >> >> >>> > --> Activating OSD ID 67 FSID 17cd6755-76f9-4160-906c-XXXXXX<br>
>     >> >> >>> > Running command: mount -t tmpfs tmpfs<br>
>     /var/lib/ceph/osd/ceph-67<br>
>     >> >> >>> > --> Absolute path not found for executable: restorecon<br>
>     >> >> >>> > --> Ensure $PATH environment variable contains common<br>
>     executable locations<br>
>     >> >> >>> > Running command: ceph-bluestore-tool --cluster=ceph<br>
>     prime-osd-dir --dev /dev/hdd67/data67 --path /var/lib/ceph/osd/ceph-67<br>
>     >> >> >>> >  stderr: failed to read label for /dev/hdd67/data67: (2)<br>
>     No such file or directory<br>
>     >> >> >>> > -->  RuntimeError: command returned non-zero exit status:<br>
>     >> >> >>><br>
>     >> >> >>> I wonder if the /dev/sdo device where hdd67/data67 is<br>
>     located is<br>
>     >> >> >>> available, or if something else is missing. You could try<br>
>     poking<br>
>     >> >> >>> around with `lvs` and see if that LV shows up, also<br>
>     `ceph-volume lvm<br>
>     >> >> >>> list hdd67/data67` can help here because it<br>
>     >> >> >>> groups OSDs to LVs. If you run `ceph-volume lvm list<br>
>     --format=json<br>
>     >> >> >>> hdd67/data67` you will also see all the metadata stored in it.<br>
>     >> >> >>><br>
>     >> >> >>> Would be interesting to see that output to verify things<br>
>     exist and are<br>
>     >> >> >>> usable for OSD activation.<br>
>     >> >> >>><br>
>     >> >> >>> ><br>
>     >> >> >>> > *******<br>
>     >> >> >>> > I then checked to see if the rest of the migrated OSDs<br>
>     were back in by calling the ceph osd tree command from the admin<br>
>     node.  Since they were not, I tried to restart the first of the 10<br>
>     newly migrated Bluestore osds by calling<br>
>     >> >> >>> ><br>
>     >> >> >>> > *******<br>
>     >> >> >>> > systemctl start ceph-osd@60<br>
>     >> >> >>> ><br>
>     >> >> >>> > At that point, not only this particular service could<br>
>     not be started, but ALL the OSDs (daemons) on the entire node shut<br>
>     down!!!!!<br>
>     >> >> >>> ><br>
>     >> >> >>> > ******<br>
>     >> >> >>> > root@osd1:~# systemctl status ceph-osd@60<br>
>     >> >> >>> > ● ceph-osd@60.service - Ceph object storage daemon osd.60<br>
>     >> >> >>> >    Loaded: loaded<br>
>     (/lib/systemd/system/ceph-<wbr>osd@.service; enabled-runtime; vendor<br>
>     preset: enabled)<br>
>     >> >> >>> >    Active: inactive (dead) since Fri 2018-11-02 15:47:20<br>
>     EDT; 1h 9min ago<br>
>     >> >> >>> >   Process: 3473621 ExecStart=/usr/bin/ceph-osd -f<br>
>     --cluster ${CLUSTER} --id %i --setuser ceph --setgroup ceph<br>
>     (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> >   Process: 3473147<br>
>     ExecStartPre=/usr/lib/ceph/ce<wbr>ph-osd-prestart.sh --cluster ${CLUSTER}<br>
>     --id %i (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> >  Main PID: 3473621 (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> ><br>
>     >> >> >>> > Oct 29 15:57:53 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</div></div>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-10-29<br>
<span>>     15:57:53.868856 7f68adaece00 -1 osd.60 48106 log_to_monitors<br>
>     {default=true}<br>
>     >> >> >>> > Oct 29 15:57:53 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-10-29<br>
<span>>     15:57:53.874373 7f68adaece00 -1 osd.60 48106<br>
>     mon_cmd_maybe_osd_create fail: 'you must complete the upgrade and<br>
>     'ceph osd require-osd-release luminous' before using crush device<br>
>     classes': (1) Operation not permitted<br>
>     >> >> >>> > Oct 30 06:25:01 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-10-30<br>
<span>>     06:25:01.961720 7f687feb3700 -1 received  signal: Hangup from  PID:<br>
>     3485955 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Oct 31 06:25:02 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-10-31<br>
<span>>     06:25:02.110898 7f687feb3700 -1 received  signal: Hangup from  PID:<br>
>     3500945 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 01 06:25:02 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-11-01<br>
<span>>     06:25:02.101548 7f687feb3700 -1 received  signal: Hangup from  PID:<br>
>     3514774 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 02 06:25:02 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-11-02<br>
<span>>     06:25:01.997557 7f687feb3700 -1 received  signal: Hangup from  PID:<br>
>     3528128 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 02 15:47:16 <a href="http://osd1.oxxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.oxxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.oxxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.oxxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-11-02<br>
<span>>     15:47:16.322229 7f687feb3700 -1 received  signal: Terminated from <br>
>     PID: 1 task name: /lib/systemd/systemd --system --deserialize 20  UID: 0<br>
>     >> >> >>> > Nov 02 15:47:16 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-11-02<br>
<span>>     15:47:16.322253 7f687feb3700 -1 osd.60 48504 *** Got signal<br>
>     Terminated ***<br>
>     >> >> >>> > Nov 02 15:47:16 <a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxxx.uky.edu</a>> ceph-osd[3473621]: 2018-11-02<br>
<span>>     15:47:16.676625 7f687feb3700 -1 osd.60 48504 shutdown<br>
>     >> >> >>> > Nov 02 16:34:05 <a href="http://osd1.oxxxxx.uky.edu" rel="noreferrer" target="_blank">osd1.oxxxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.oxxxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.oxxxxx.uky.edu</a>> systemd[1]: Stopped Ceph object storage<br>
<span>>     daemon osd.60.<br>
>     >> >> >>> ><br>
>     >> >> >>> > **********<br>
>     >> >> >>> > And ere is the output for one of the OSDs (osd.70 still<br>
>     using Filestore) that shut down right when I tried to start osd.60<br>
>     >> >> >>> ><br>
>     >> >> >>> > ********<br>
>     >> >> >>> ><br>
>     >> >> >>> > root@osd1:~# systemctl status ceph-osd@70<br>
>     >> >> >>> > ● ceph-osd@70.service - Ceph object storage daemon osd.70<br>
>     >> >> >>> >    Loaded: loaded<br>
>     (/lib/systemd/system/ceph-<wbr>osd@.service; enabled-runtime; vendor<br>
>     preset: enabled)<br>
>     >> >> >>> >    Active: inactive (dead) since Fri 2018-11-02 16:34:08<br>
>     EDT; 2min 6s ago<br>
>     >> >> >>> >   Process: 3473629 ExecStart=/usr/bin/ceph-osd -f<br>
>     --cluster ${CLUSTER} --id %i --setuser ceph --setgroup ceph<br>
>     (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> >   Process: 3473153<br>
>     ExecStartPre=/usr/lib/ceph/ce<wbr>ph-osd-prestart.sh --cluster ${CLUSTER}<br>
>     --id %i (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> >  Main PID: 3473629 (code=exited, status=0/SUCCESS)<br>
>     >> >> >>> ><br>
>     >> >> >>> > Oct 29 15:57:51 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-10-29<br>
<span>>     15:57:51.300563 7f530eec2e00 -1 osd.70 pg_epoch: 48095 pg[68.ces1(<br>
>     empty local-lis/les=47489/47489 n=0 ec=6030/6030 lis/c 47488/47488<br>
>     les/c/f 47489/47489/0 47485/47488/47488) [138,70,203]p138(0) r=1<br>
>     lpr=0 crt=0'0 unknown NO<br>
>     >> >> >>> > Oct 30 06:25:01 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-10-30<br>
<span>>     06:25:01.961743 7f52d8e44700 -1 received  signal: Hangup from  PID:<br>
>     3485955 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Oct 31 06:25:02 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-10-31<br>
<span>>     06:25:02.110920 7f52d8e44700 -1 received  signal: Hangup from  PID:<br>
>     3500945 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 01 06:25:02 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-11-01<br>
<span>>     06:25:02.101568 7f52d8e44700 -1 received  signal: Hangup from  PID:<br>
>     3514774 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 02 06:25:02 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-11-02<br>
<span>>     06:25:01.997633 7f52d8e44700 -1 received  signal: Hangup from  PID:<br>
>     3528128 task name: killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd<br>
>     ceph-fuse radosgw  UID: 0<br>
>     >> >> >>> > Nov 02 16:34:05 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-11-02<br>
<span>>     16:34:05.607714 7f52d8e44700 -1 received  signal: Terminated from <br>
>     PID: 1 task name: /lib/systemd/systemd --system --deserialize 20  UID: 0<br>
>     >> >> >>> > Nov 02 16:34:05 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-11-02<br>
<span>>     16:34:05.607738 7f52d8e44700 -1 osd.70 48535 *** Got signal<br>
>     Terminated ***<br>
>     >> >> >>> > Nov 02 16:34:05 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> systemd[1]: Stopping Ceph object storage<br>
<span>>     daemon osd.70...<br>
>     >> >> >>> > Nov 02 16:34:05 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> ceph-osd[3473629]: 2018-11-02<br>
<span>>     16:34:05.677348 7f52d8e44700 -1 osd.70 48535 shutdown<br>
>     >> >> >>> > Nov 02 16:34:08 <a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">osd1.xxxx.uky.edu</a><br>
</span>>     <<a href="http://osd1.xxxx.uky.edu" rel="noreferrer" target="_blank">http://osd1.xxxx.uky.edu</a>> systemd[1]: Stopped Ceph object storage<br>
<div><div>>     daemon osd.70.<br>
>     >> >> >>> ><br>
>     >> >> >>> > **************<br>
>     >> >> >>> ><br>
>     >> >> >>> > So, at this point, ALL the OSDs on that node have been<br>
>     shut down.<br>
>     >> >> >>> ><br>
>     >> >> >>> > For your information this is the output of lsblk command<br>
>     (selection)<br>
>     >> >> >>> > *****<br>
>     >> >> >>> > root@osd1:~# lsblk<br>
>     >> >> >>> > NAME           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT<br>
>     >> >> >>> > sda              8:0    0 447.1G  0 disk<br>
>     >> >> >>> > ├─ssd0-db60    252:0    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db61    252:1    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db62    252:2    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db63    252:3    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db64    252:4    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db65    252:5    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db66    252:6    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db67    252:7    0    40G  0 lvm<br>
>     >> >> >>> > ├─ssd0-db68    252:8    0    40G  0 lvm<br>
>     >> >> >>> > └─ssd0-db69    252:9    0    40G  0 lvm<br>
>     >> >> >>> > sdb              8:16   0 447.1G  0 disk<br>
>     >> >> >>> > ├─sdb1           8:17   0    40G  0 part<br>
>     >> >> >>> > ├─sdb2           8:18   0    40G  0 part<br>
>     >> >> >>> ><br>
>     >> >> >>> > .....<br>
>     >> >> >>> ><br>
>     >> >> >>> > sdh              8:112  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd60-data60 252:10   0   3.7T  0 lvm<br>
>     >> >> >>> > sdi              8:128  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd61-data61 252:11   0   3.7T  0 lvm<br>
>     >> >> >>> > sdj              8:144  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd62-data62 252:12   0   3.7T  0 lvm<br>
>     >> >> >>> > sdk              8:160  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd63-data63 252:13   0   3.7T  0 lvm<br>
>     >> >> >>> > sdl              8:176  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd64-data64 252:14   0   3.7T  0 lvm<br>
>     >> >> >>> > sdm              8:192  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd65-data65 252:15   0   3.7T  0 lvm<br>
>     >> >> >>> > sdn              8:208  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd66-data66 252:16   0   3.7T  0 lvm<br>
>     >> >> >>> > sdo              8:224  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd67-data67 252:17   0   3.7T  0 lvm<br>
>     >> >> >>> > sdp              8:240  0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd68-data68 252:18   0   3.7T  0 lvm<br>
>     >> >> >>> > sdq             65:0    0   3.7T  0 disk<br>
>     >> >> >>> > └─hdd69-data69 252:19   0   3.7T  0 lvm<br>
>     >> >> >>> > sdr             65:16   0   3.7T  0 disk<br>
>     >> >> >>> > └─sdr1          65:17   0   3.7T  0 part<br>
>     /var/lib/ceph/osd/ceph-70<br>
>     >> >> >>> > .....<br>
>     >> >> >>> ><br>
>     >> >> >>> > As a Ceph novice, I am totally clueless about the next<br>
>     step at this point.  Any help would be appreciated.<br>
>     >> >> >>> ><br>
>     >> >> >>> > On Thu, Nov 1, 2018 at 3:16 PM, Hayashida, Mami<br>
</div></div><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> >> >>> >><br>
>     >> >> >>> >> Thank you, both of you.  I will try this out very soon.<br>
>     >> >> >>> >><br>
>     >> >> >>> >> On Wed, Oct 31, 2018 at 8:48 AM, Alfredo Deza<br>
</span><span>>     <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a> <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
>     >> >> >>> >>><br>
>     >> >> >>> >>> On Wed, Oct 31, 2018 at 8:28 AM Hayashida, Mami<br>
</span><span>>     <<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>>> wrote:<br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > Thank you for your replies. So, if I use the method<br>
>     Hector suggested (by creating PVs, VGs.... etc. first), can I add<br>
>     the --osd-id parameter to the command as in<br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > ceph-volume lvm prepare --bluestore --data<br>
>     hdd0/data0 --block.db ssd/db0  --osd-id 0<br>
>     >> >> >>> >>> > ceph-volume lvm prepare --bluestore --data<br>
>     hdd1/data1 --block.db ssd/db1  --osd-id 1<br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > so that Filestore -> Bluestore migration will not<br>
>     change the osd ID on each disk?<br>
>     >> >> >>> >>><br>
>     >> >> >>> >>> That looks correct.<br>
>     >> >> >>> >>><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > And one more question.  Are there any changes I need<br>
>     to make to the ceph.conf file?  I did comment out this line that was<br>
>     probably used for creating Filestore (using ceph-deploy):  osd<br>
>     journal size = 40960<br>
>     >> >> >>> >>><br>
>     >> >> >>> >>> Since you've pre-created the LVs the commented out<br>
>     line will not<br>
>     >> >> >>> >>> affect anything.<br>
>     >> >> >>> >>><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > On Wed, Oct 31, 2018 at 7:03 AM, Alfredo Deza<br>
</span><span>>     <<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a> <mailto:<a href="mailto:adeza@redhat.com" target="_blank">adeza@redhat.com</a>>> wrote:<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> On Wed, Oct 31, 2018 at 5:22 AM Hector Martin<br>
</span><span>>     <<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a> <mailto:<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a>><wbr>> wrote:<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > On 31/10/2018 05:55, Hayashida, Mami wrote:<br>
>     >> >> >>> >>> >> > > I am relatively new to Ceph and need some<br>
>     advice on Bluestore migration.<br>
>     >> >> >>> >>> >> > > I tried migrating a few of our test cluster<br>
>     nodes from Filestore to<br>
>     >> >> >>> >>> >> > > Bluestore by following this<br>
>     >> >> >>> >>> >> > ><br>
>     (<a href="http://docs.ceph.com/docs/luminous/rados/operations/bluestore-migration/" rel="noreferrer" target="_blank">http://docs.ceph.com/docs/lu<wbr>minous/rados/operations/bluest<wbr>ore-migration/</a><br>
</span>>     <<a href="http://docs.ceph.com/docs/luminous/rados/operations/bluestore-migration/" rel="noreferrer" target="_blank">http://docs.ceph.com/docs/lu<wbr>minous/rados/operations/bluest<wbr>ore-migration/</a>>)<br>
<div><div>>     >> >> >>> >>> >> > > as the cluster is currently running 12.2.9. The<br>
>     cluster, originally set<br>
>     >> >> >>> >>> >> > > up by my predecessors, was running Jewel until<br>
>     I upgraded it recently to<br>
>     >> >> >>> >>> >> > > Luminous.<br>
>     >> >> >>> >>> >> > ><br>
>     >> >> >>> >>> >> > > OSDs in each OSD host is set up in such a way<br>
>     that for ever 10 data HDD<br>
>     >> >> >>> >>> >> > > disks, there is one SSD drive that is holding<br>
>     their journals.  For<br>
>     >> >> >>> >>> >> > > example, osd.0 data is on /dev/sdh and its<br>
>     Filestore journal is on a<br>
>     >> >> >>> >>> >> > > partitioned part of /dev/sda. So, lsblk shows<br>
>     something like<br>
>     >> >> >>> >>> >> > ><br>
>     >> >> >>> >>> >> > > sda       8:0    0 447.1G  0 disk<br>
>     >> >> >>> >>> >> > > ├─sda1    8:1    0    40G  0 part # journal for<br>
>     osd.0<br>
>     >> >> >>> >>> >> > ><br>
>     >> >> >>> >>> >> > > sdh       8:112  0   3.7T  0 disk<br>
>     >> >> >>> >>> >> > > └─sdh1    8:113  0   3.7T  0 part<br>
>     /var/lib/ceph/osd/ceph-0<br>
>     >> >> >>> >>> >> > ><br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > The BlueStore documentation states that the wal<br>
>     will automatically use<br>
>     >> >> >>> >>> >> > the db volume if it fits, so if you're using a<br>
>     single SSD I think<br>
>     >> >> >>> >>> >> > there's no good reason to split out the wal, if<br>
>     I'm understanding it<br>
>     >> >> >>> >>> >> > correctly.<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> This is correct, no need for wal in this case.<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > You should be using ceph-volume, since ceph-disk<br>
>     is deprecated. If<br>
>     >> >> >>> >>> >> > you're sharing the SSD as wal/db for a bunch of<br>
>     OSDs, I think you're<br>
>     >> >> >>> >>> >> > going to have to create the LVs yourself first.<br>
>     The data HDDs should be<br>
>     >> >> >>> >>> >> > PVs (I don't think it matters if they're<br>
>     partitions or whole disk PVs as<br>
>     >> >> >>> >>> >> > long as LVM discovers them) each part of a<br>
>     separate VG (e.g. hdd0-hdd9)<br>
>     >> >> >>> >>> >> > containing a single LV. Then the SSD should<br>
>     itself be an LV for a<br>
>     >> >> >>> >>> >> > separate shared SSD VG (e.g. ssd).<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > So something like (assuming sda is your wal SSD<br>
>     and sdb and onwards are<br>
>     >> >> >>> >>> >> > your OSD HDDs):<br>
>     >> >> >>> >>> >> > pvcreate /dev/sda<br>
>     >> >> >>> >>> >> > pvcreate /dev/sdb<br>
>     >> >> >>> >>> >> > pvcreate /dev/sdc<br>
>     >> >> >>> >>> >> > ...<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > vgcreate ssd /dev/sda<br>
>     >> >> >>> >>> >> > vgcreate hdd0 /dev/sdb<br>
>     >> >> >>> >>> >> > vgcreate hdd1 /dev/sdc<br>
>     >> >> >>> >>> >> > ...<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > lvcreate -L 40G -n db0 ssd<br>
>     >> >> >>> >>> >> > lvcreate -L 40G -n db1 ssd<br>
>     >> >> >>> >>> >> > ...<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > lvcreate -L 100%VG -n data0 hdd0<br>
>     >> >> >>> >>> >> > lvcreate -L 100%VG -n data1 hdd1<br>
>     >> >> >>> >>> >> > ...<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > ceph-volume lvm prepare --bluestore --data<br>
>     hdd0/data0 --block.db ssd/db0<br>
>     >> >> >>> >>> >> > ceph-volume lvm prepare --bluestore --data<br>
>     hdd1/data1 --block.db ssd/db1<br>
>     >> >> >>> >>> >> > ...<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > ceph-volume lvm activate --all<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > I think it might be possible to just let<br>
>     ceph-volume create the PV/VG/LV<br>
>     >> >> >>> >>> >> > for the data disks and only manually create the<br>
>     DB LVs, but it shouldn't<br>
>     >> >> >>> >>> >> > hurt to do it on your own and just give<br>
>     ready-made LVs to ceph-volume<br>
>     >> >> >>> >>> >> > for everything.<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> Another alternative here is to use the new `lvm<br>
>     batch` subcommand to<br>
>     >> >> >>> >>> >> do all of this in one go:<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> ceph-volume lvm batch /dev/sda /dev/sdb /dev/sdc<br>
>     /dev/sdd /dev/sde<br>
>     >> >> >>> >>> >> /dev/sdf /dev/sdg /dev/sdh<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> Will detect that sda is an SSD and will create the<br>
>     LVs for you for<br>
>     >> >> >>> >>> >> block.db (one for each spinning disk). For each<br>
>     spinning disk, it will<br>
>     >> >> >>> >>> >> place data on them.<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> The one caveat is that you no longer control OSD<br>
>     IDs, and they are<br>
>     >> >> >>> >>> >> created with whatever the monitors are giving out.<br>
>     >> >> >>> >>> >><br>
>     >> >> >>> >>> >> This operation is not supported from ceph-deploy<br>
>     either.<br>
>     >> >> >>> >>> >> ><br>
>     >> >> >>> >>> >> > --<br>
>     >> >> >>> >>> >> > Hector Martin (<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a><br>
</div></div>>     <mailto:<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a><wbr>>)<br>
<span>>     >> >> >>> >>> >> > Public Key: <a href="https://marcan.st/marcan.asc" rel="noreferrer" target="_blank">https://marcan.st/marcan.asc</a><br>
>     >> >> >>> >>> >> > ______________________________<wbr>_________________<br>
>     >> >> >>> >>> >> > ceph-users mailing list<br>
>     >> >> >>> >>> >> > <a href="mailto:ceph-users@lists.ceph.com" target="_blank">ceph-users@lists.ceph.com</a><br>
</span>>     <mailto:<a href="mailto:ceph-users@lists.ceph.com" target="_blank">ceph-users@lists.<wbr>ceph.com</a>><br>
>     >> >> >>> >>> >> ><br>
>     <a href="http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com" rel="noreferrer" target="_blank">http://lists.ceph.com/listinf<wbr>o.cgi/ceph-users-ceph.com</a><br>
<span>>     <<a href="http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com" rel="noreferrer" target="_blank">http://lists.ceph.com/listin<wbr>fo.cgi/ceph-users-ceph.com</a>><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > --<br>
>     >> >> >>> >>> > Mami Hayashida<br>
>     >> >> >>> >>> > Research Computing Associate<br>
>     >> >> >>> >>> ><br>
>     >> >> >>> >>> > Research Computing Infrastructure<br>
>     >> >> >>> >>> > University of Kentucky Information Technology Services<br>
>     >> >> >>> >>> > 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> >> >>> >>> > Lexington, KY 40506-0495<br>
</span>>     >> >> >>> >>> > <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> >> >>> >>> > (859)323-7521<br>
>     >> >> >>> >><br>
>     >> >> >>> >><br>
>     >> >> >>> >><br>
>     >> >> >>> >><br>
>     >> >> >>> >> --<br>
>     >> >> >>> >> Mami Hayashida<br>
>     >> >> >>> >> Research Computing Associate<br>
>     >> >> >>> >><br>
>     >> >> >>> >> Research Computing Infrastructure<br>
>     >> >> >>> >> University of Kentucky Information Technology Services<br>
>     >> >> >>> >> 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> >> >>> >> Lexington, KY 40506-0495<br>
</span>>     >> >> >>> >> <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> >> >>> >> (859)323-7521<br>
>     >> >> >>> ><br>
>     >> >> >>> ><br>
>     >> >> >>> ><br>
>     >> >> >>> ><br>
>     >> >> >>> > --<br>
>     >> >> >>> > Mami Hayashida<br>
>     >> >> >>> > Research Computing Associate<br>
>     >> >> >>> ><br>
>     >> >> >>> > Research Computing Infrastructure<br>
>     >> >> >>> > University of Kentucky Information Technology Services<br>
>     >> >> >>> > 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> >> >>> > Lexington, KY 40506-0495<br>
</span>>     >> >> >>> > <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> >> >>> > (859)323-7521<br>
>     >> >> >><br>
>     >> >> >><br>
>     >> >> >><br>
>     >> >> >><br>
>     >> >> >> --<br>
>     >> >> >> Mami Hayashida<br>
>     >> >> >> Research Computing Associate<br>
>     >> >> >><br>
>     >> >> >> Research Computing Infrastructure<br>
>     >> >> >> University of Kentucky Information Technology Services<br>
>     >> >> >> 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> >> >> Lexington, KY 40506-0495<br>
</span>>     >> >> >> <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> >> >> (859)323-7521<br>
>     >> >> ><br>
>     >> >> ><br>
>     >> >> ><br>
>     >> >> ><br>
>     >> >> > --<br>
>     >> >> > Mami Hayashida<br>
>     >> >> > Research Computing Associate<br>
>     >> >> ><br>
>     >> >> > Research Computing Infrastructure<br>
>     >> >> > University of Kentucky Information Technology Services<br>
>     >> >> > 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> >> > Lexington, KY 40506-0495<br>
</span>>     >> >> > <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> >> > (859)323-7521<br>
>     >> ><br>
>     >> ><br>
>     >> ><br>
>     >> ><br>
>     >> > --<br>
>     >> > Mami Hayashida<br>
>     >> > Research Computing Associate<br>
>     >> ><br>
>     >> > Research Computing Infrastructure<br>
>     >> > University of Kentucky Information Technology Services<br>
>     >> > 301 Rose Street | 102 James F. Hardymon Building<br>
>     >> > Lexington, KY 40506-0495<br>
</span>>     >> > <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
<span>>     >> > (859)323-7521<br>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
>     > --<br>
>     > Mami Hayashida<br>
>     > Research Computing Associate<br>
>     ><br>
>     > Research Computing Infrastructure<br>
>     > University of Kentucky Information Technology Services<br>
>     > 301 Rose Street | 102 James F. Hardymon Building<br>
>     > Lexington, KY 40506-0495<br>
</span>>     > <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
>     > (859)323-7521<br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> *Mami Hayashida*<br>
> /Research Computing Associate<br>
> /<br>
<span>> Research Computing Infrastructure<br>
> University of Kentucky Information Technology Services<br>
> 301 Rose Street | 102 James F. Hardymon Building<br>
> Lexington, KY 40506-0495<br>
</span>> <a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a> <mailto:<a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><wbr>><br>
> (859)323-7521<br>
<span><font color="#888888"><br>
<br>
-- <br>
Hector Martin (<a href="mailto:hector@marcansoft.com" target="_blank">hector@marcansoft.com</a>)<br>
Public Key: <a href="https://mrcn.st/pub" rel="noreferrer" target="_blank">https://mrcn.st/pub</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div class="h5"><div><b style="font-size:12.8px">Mami Hayashida</b><br></div><div><i>Research Computing Associate<br></i><br></div></div></div><div><div><div class="h5">Research Computing Infrastructure<br>University of Kentucky Information Technology Services <br>301 Rose Street | 102 James F. Hardymon Building<br>Lexington, KY 40506-0495<br><a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><br></div></div>(859)323-7521</div></div></div></div></div></div></div></div></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b style="font-size:12.8px">Mami Hayashida</b><br></div><div><i>Research Computing Associate<br></i><br></div><div>Research Computing Infrastructure<br>University of Kentucky Information Technology Services <br>301 Rose Street | 102 James F. Hardymon Building<br>Lexington, KY 40506-0495<br><a href="mailto:mami.hayashida@uky.edu" target="_blank">mami.hayashida@uky.edu</a><br>(859)323-7521</div></div></div></div></div></div></div></div></div>
</div>