[Gluster-devel] RPM / BerkeleyDB on GlusterFS

[Brent A Nelson]

I believe you're looking for shared writable mmap support, which requires 
a very recent (maybe) or painfully-patched FUSE; it's not really up to 
GlusterFS (I think it will probably just work, if your FUSE is somehow 
able to support it).

I tried to patch my FUSE and gave up (the patches I found didn't work and 
caused crashes).  I was looking because apt-get uses shared writable 
mmap.  I found that someone had posted a workaround whereby you'd place 
the files requiring shared writable mmap in a tmpfs filesystem; I tried 
that, and it worked fine.  For apt-get, it wasn't a big deal, as the 
mmapped files are just caches; I don't know if the rpm files are something 
that would need to be permanent, in which case you'd need to copy the 
files in and out of the tmpfs to keep them across reboots.

So, if you can't get shared writable mmap to work, try the workaround 
with tmpfs or another filesystem (perhaps even an NFS mount of a GlusterFS 
directory).

Thanks,

Brent Nelson
Director of Computing
UF Physics

On Mon, 12 Jan 2009, Gordan Bobic wrote:

> Hi,
>
> I'm working on a root-on-glusterfs system and I have almost all of it working 
> now, but one things that seems to be having problems is RPM (Berkeley DB). 
> When I attempt to access/query the database that is on glusterfs, I get the 
> following error:
>
> rpmdb: mmap: No such device
> error: db4 error(19) from dbenv->open: No such device
> error: cannot open Packages index using db3 - No such device (19)
> error: cannot open Packages database in /var/lib/rpm
>
> From the error, it looks like it is having a problem with mmap (or lack 
> thereof). Presumably, it wants writable mmap.
>
> So:
>
> 1) Is there writable mmap support anywhere on the horizon for GlusterFS?
> 2) Does anyone know if there is a way to make the RPM DB work without mmap?
>
> The only other workaround I can think of that could be applied (I am only 
> interested in AFR/mirroring) would be to set up DRBD+GFS just for replicating 
> the RPM DB, but that's a bit lame, because the main reason for using 
> GlusterFS for a shared-root environment is specifically to avoid having to 
> use a block level mirroring solution like DRBD+GFS.
>
> Has anyone got any ideas on this?
>
> Thanks.
>
> Gordan
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>