GlusterFs: Problems with Memory Mapped Files and "apt-get" on debian

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I have a problem with "mmap" on my GlusterFs test environment and "apt" on Debian.

My environment:
Hardware:
2 different servers for storage
1 server as client
On top of the server I use a virtual server setup (details http://linux-vserver.org).

OS:
Debian Sarge with self compiled 2.6.19.2 (uname -r 2.6.19.2-vs2.2.0) and latest stable virtual server patch.
GlusterFs: latest mainline 2.4 from repository

What I'm trying to do:
- Create a AFR Mirror over the 2 Servers.
- Mount the Volume on Server 3 (Client).
- Install on the mounted volume the hole virtual Server with Apache, MySql and so on.
So I have a full redundant Virtual Server mirrored over two bricks .

After some help from Avati Anand last week the above setup works just fine. I tried out Mysql and it works normally (will make some more tests in the future).

But now I have the problem with apt.
For example when I try to update the packagelists within the virtual server I get the following error:
mastersql:/# apt-get update
Get:1 http://security.debian.org etch/updates Release.gpg [189B] ... Hit http://ftp.de.debian.org etch/non-free Packages

Fetched 2B in 7s (0B/s)
Reading package lists... Error!
E: Couldn't make mmap of 12582912 bytes - mmap (19 No such device)
W: Unable to munmap
E: The package lists or status file could not be parsed or opened.

After some googling I found out, that apt uses "memory mapped files" and it seems that apt can't find some device.
But I'm not able to find out which device does it can't find.

Short description of MMAP: http://www.ecst.csuchico.edu/~beej/guide/ipc/mmap.html

Have you any idea what can cause this problem? Without GlusterFs as the underlaying filesystem the problems not occurs.

thanks
Urban Loesch





Krishna Srinivas wrote:
Hi Danson,

Updating the replica only on the next access is not the best
solution for the reasons mentioned by you. We will announce
the AFR's auto-sync design to the list soon. It is scheduled
for 1.4.

Regards
Krishna

On 5/12/07, Danson Michael Joseph <danson.joseph@xxxxxxxxxxxxxxxxxx> wrote:
Hi Again,

I just read that the CODA filesystem can replicate to multiple servers,
and when a server goes down and comes back up some time after files on
the remaining server have changed, the policy for repair is to repair on
next access.  Now I don't believe that this policy is ideal because if
the second server then fails before a file has been accessed, the file
is not up to date, but it does highlight a possible repair technique
whereby the client does a loopback write for all files with different
timestamps or some other marked difference?

Regards,
Danson


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel



_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel





[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux