From: Gordan B. <go...@bo...> - 2009-01-14 16:10:05
|
On Wed 14/01/09 15:37 , Marc Grimme <gr...@at...> wrote: > On Wednesday 14 January 2009 12:07:11 Gordan Bobic wrote: > > Hi, > > > > I have GlusterFS OSR working and I'll be sending a patch when I > have done a > > bit more testing including rebuilding a fresh system from scratch > to test > > my notes/documentation which I'll also be submitting. > > Sounds great. I'll be happy to bring this upstream. Thanks. Sorry it took this long (I first mentioned the idea some months ago). There were some bugs in GlusterFS that made it too unstable for production (for my use-cases at least), so I left it on hold until I was happy with it in the standard environment. Some of the notable things that were required to get OSR working with it were: - fuse needs /tmp to exist before it'll work. The error it returns is entirely misleading, and this took a while to get to the bottom of. Until now, OSR didn't include a /tmp directory. - RPM refused to work because it is based on BerkeleyDB, which requires writable mmap support, which isn't available in fuse. The solution for that was to convert the RPM DB to SQLite. > > Either way, I copied the halt script across and added glusterfs to > the list > > of things to not kill (-x parameter), but this didn't appear to > make any > > difference. The man page for killall/killall5 on RHEL5 doesn't > appear to > > list the -x option (although I did find a reference to this > parameter being > > added in Debian in 2006). Is this known to work on RHEL/CentOS 5, > or is > > there a modified killall required for this distro? > Normally this binary that does this killing is the rpm > SysVinit-comoonics > found at > > http://download.atix.de/yum/comoonics/redhat-el5/productive/x86_64/RPMS/. > > This provides a new killall found at /usr/comoonics/sbin. This is > called by > halt and accepts the -x as option. > Let me know if this is enough information. I'll double-check, but I'm almost certain that this package was installed. Does the same package also include the modified halt init script? Thanks. Gordan ---- Msg sent via @Mail - http://atmail.com/ |
From: Christopher B. <chr...@ql...> - 2009-01-14 16:20:03
|
> -----Original Message----- > From: Gordan Bobic [mailto:go...@bo...] > Sent: Wednesday, January 14, 2009 11:10 AM > To: ope...@li... > Subject: Re: [OSR-devel] killall and init scripts > > On Wed 14/01/09 15:37 , Marc Grimme <gr...@at...> wrote: > > On Wednesday 14 January 2009 12:07:11 Gordan Bobic wrote: > > > Hi, > > > > > > I have GlusterFS OSR working and I'll be sending a patch when I > > have done a ==========snip=8<----------- > > Some of the notable things that were required to get OSR > working with it were: > - fuse needs /tmp to exist before it'll work. The error it > returns is entirely misleading, and this took a while to get > to the bottom of. Until now, OSR didn't include a /tmp directory. is the $TMPDIR variable not honored/effective? > - RPM refused to work because it is based on BerkeleyDB, > which requires writable mmap support, which isn't available > in fuse. The solution for that was to convert the RPM DB to SQLite. > Amazing stuff you all are doing here. Great work. -C |
From: Marc G. <gr...@at...> - 2009-01-14 19:22:38
|
On Wednesday 14 January 2009 17:09:54 Gordan Bobic wrote: > On Wed 14/01/09 15:37 , Marc Grimme <gr...@at...> wrote: > > On Wednesday 14 January 2009 12:07:11 Gordan Bobic wrote: > > > Hi, > > > > > > I have GlusterFS OSR working and I'll be sending a patch when I > > > > have done a > > > > > bit more testing including rebuilding a fresh system from scratch > > > > to test > > > > > my notes/documentation which I'll also be submitting. > > > > Sounds great. I'll be happy to bring this upstream. > > Thanks. Sorry it took this long (I first mentioned the idea some months > ago). There were some bugs in GlusterFS that made it too unstable for > production (for my use-cases at least), so I left it on hold until I was > happy with it in the standard environment. > > Some of the notable things that were required to get OSR working with it > were: - fuse needs /tmp to exist before it'll work. The error it returns is > entirely misleading, and this took a while to get to the bottom of. Until > now, OSR didn't include a /tmp directory. - RPM refused to work because it > is based on BerkeleyDB, which requires writable mmap support, which isn't > available in fuse. The solution for that was to convert the RPM DB to > SQLite. That's interesting cause I always wandered if it is possible to change the db underneath. We also have so issues with gfs and rpmdb<berkeleydb>. Can you point out some online resources on how to do this? > > > > Either way, I copied the halt script across and added glusterfs to > > > > the list > > > > > of things to not kill (-x parameter), but this didn't appear to > > > > make any > > > > > difference. The man page for killall/killall5 on RHEL5 doesn't > > > > appear to > > > > > list the -x option (although I did find a reference to this > > > > parameter being > > > > > added in Debian in 2006). Is this known to work on RHEL/CentOS 5, > > > > or is > > > > > there a modified killall required for this distro? > > > > Normally this binary that does this killing is the rpm > > SysVinit-comoonics > > found at > > > > http://download.atix.de/yum/comoonics/redhat-el5/productive/x86_64/RPMS/. > > > > This provides a new killall found at /usr/comoonics/sbin. This is > > called by > > halt and accepts the -x as option. > > Let me know if this is enough information. > > I'll double-check, but I'm almost certain that this package was installed. > Does the same package also include the modified halt init script? No those are added by comoonics-bootimage-initscripts. These provide the patches needed. -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |
From: Gordan B. <go...@bo...> - 2009-01-14 22:34:37
|
Marc Grimme wrote: >>>> I have GlusterFS OSR working and I'll be sending a patch when I >>> have done a >>> >>>> bit more testing including rebuilding a fresh system from scratch >>> to test >>> >>>> my notes/documentation which I'll also be submitting. >>> Sounds great. I'll be happy to bring this upstream. >> Thanks. Sorry it took this long (I first mentioned the idea some months >> ago). There were some bugs in GlusterFS that made it too unstable for >> production (for my use-cases at least), so I left it on hold until I was >> happy with it in the standard environment. >> >> Some of the notable things that were required to get OSR working with it >> were: - fuse needs /tmp to exist before it'll work. The error it returns is >> entirely misleading, and this took a while to get to the bottom of. Until >> now, OSR didn't include a /tmp directory. - RPM refused to work because it >> is based on BerkeleyDB, which requires writable mmap support, which isn't >> available in fuse. The solution for that was to convert the RPM DB to >> SQLite. > > That's interesting cause I always wandered if it is possible to change the db > underneath. We also have so issues with gfs and rpmdb<berkeleydb>. Can you > point out some online resources on how to do this? I'll definitely include it in the docs when I've got it all ready. Hopefully by the end of the week. I just want to make sure that my results are repeatable first. :) >>>> Either way, I copied the halt script across and added glusterfs to >>> the list >>> >>>> of things to not kill (-x parameter), but this didn't appear to >>> make any >>> >>>> difference. The man page for killall/killall5 on RHEL5 doesn't >>> appear to >>> >>>> list the -x option (although I did find a reference to this >>> parameter being >>> >>>> added in Debian in 2006). Is this known to work on RHEL/CentOS 5, >>> or is >>> >>>> there a modified killall required for this distro? >>> Normally this binary that does this killing is the rpm >>> SysVinit-comoonics >>> found at >>> >>> http://download.atix.de/yum/comoonics/redhat-el5/productive/x86_64/RPMS/. >>> >>> This provides a new killall found at /usr/comoonics/sbin. This is >>> called by >>> halt and accepts the -x as option. >>> Let me know if this is enough information. >> I'll double-check, but I'm almost certain that this package was installed. >> Does the same package also include the modified halt init script? > > No those are added by comoonics-bootimage-initscripts. These provide the > patches needed. Thanks, I'll have another look at it and see what I've missed. Gordan |