[Top][All Lists]

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

Re: Large filesystems

From: Jon Arney
Subject: Re: Large filesystems
Date: Mon, 18 Feb 2002 18:08:29 -0700


I can actually mount the first partition (/hurd) as my root filesystem
using the server.boot script and grub command-line.  It doesn't complain
about anything and seems to work just fine although I haven't filled
the filesystem yet, so it may begin to complain when I do fill it.

As to the other filesystems, what I do is the following (under the hurd)

settrans /src /hurd/ext2fs /dev/hd2s2
settrans /opt /hurd/ext2fs /dev/hd1s1

In both cases, I am able to mount the filesystem properly and 'ps'
shows the translators running.

When I do an 'ls -la /opt/*/*' I see the full listing of the
.tar.gz files I've stored there and they _appear_ to be correct.

When I do an 'ls -la /src/*' I see a listing of some of the
files there, but the list is interrupted by something like
'ls: Computer bought the farm' on certain files.  Upon inspection,
the files which seem to be more likely to show this behavior are
ones with 'large' inode numbers.

I also used a test program to probe this:

#include <sys/stat.h>
#include <stdio.h>
int main(int argc, char **argv)
        int rc;
        struct stat statbuf;
        rc = stat("/src/rpm", &statbuf);

Running this program produces 'foo: Computer bought the farm'.

After running this or the 'ls' I find that /hurd/ext2fs
is no longer running and has been replaced with /hurd/crash.

After looking through the hurd and mach sources, I believe that 
part of the trouble is that in 'storeio' and 'ext2fs' the type
used for sizes and offsets are 'off_t' which is defined to
be 'natural_t' which is defined to be 'unsigned long'.  I believe
that part of the solution could be to replace these with 'off64_t'
but it seems that much care would be required in making these
changes.  What I am most concerned about is the buffer interface
with 'vm_offset_t' which is also defined to be 'natural_t' and
thus the VM buffering of pages with offsets larger than 32 bit
would be comprimised.

Niels M\xF6ller wrote:
> Jon Arney <address@hidden> writes:
> > I'm running into a problem, however, when I mount (set translator for)
> > one of the filesystems.
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/hdc1              2015984    739996   1173580  39% /hurd
> > /dev/hdc2              5039592   1605844   3177744  34% /hurd/src
> > /dev/hdb1               958977    703747    205690  78% /mnt/hdd1
> There's a known limitation in the ext2 translator at about 1GB, so you
> are not supposed to be able to mount your first two ext2 partitions
> under the hurd at all, which should be mentioned in any Hurd FAQ. But
> I think you would get errors when the translator is first activated,
> before you get the chance to access files on it.
> So what you report seems quite odd to me. Can you describe exactly
> what you do, and what error messages you get?
> You should be able to mount larger filesystem via NFS from a remote
> machine, though.
> /Niels

Jonathan S. Arney
Software Engineer
(602) - 589 - 6654

reply via email to

[Prev in Thread] Current Thread [Next in Thread]