empty symlinks, e2fsck

2002-12-22 Thread Moritz Schulte
Hi,

I created an empty symlink on an ext2 filesystem while I was in
GNU/Hurd.  Later on that partitions was checked by e2fsck (in
GNU/Linux) and when it encountered that symlink, it reported a
filesystem inconsistency, which I had to repair manually.

That doesn't seem so sane to me, either ext2fs should not allow such
links or it shouldn't be a serious filesystem error.  Or am I wrong?

moritz
-- 
[EMAIL PROTECTED] - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06  B501 0841 2D7B 6F98 4199


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd



Re: empty symlinks, e2fsck

2002-12-22 Thread Roland McGrath
I'd call that a bug in e2fsck.  Empty symlinks used to be creatable and
work on GNU/Linux as well.  It would be fine to disallow them, however.


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd



Re: Some ideas for GNUmach2 (oskit-mach)

2002-12-22 Thread Daniel Wagner
Joachim Nilsson <[EMAIL PROTECTED]> writes:

>   1. Change the OSKit version dependency in configure.in to,
>  at least, NEEDED_OSKIT_VERION=20010214. The changes for

Yes, that's not a bad idea. 

>   2. When I build an optimized kernel, only IDE and one
>  ethernet card, e.g., kernel-ide+ethernet_tulip the installed
>  kernel is not what I opted for.
>  
>  The install_kernel target in the makefile installs kernel,
>  not kernel-ide+ethernet_tulip.

I see another problem with the kernel-DRIVER strategy. Currently a
serial driver is missing for gnumach2. So modem users can't go
online. OSKit has some character drivers, mainly in the FreeBSD part
of the driver libs (liboskit_freebsd_devs). Right now only the
Linux drivers (liboskit_linux_devs) are used for gnumach2. But when we
want to use the char drivers we need to load drivers from FreeBSD. I
don't know if the cool kernel-DRIVER configuration will work anymore.

daniel


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd



Re: 2nd attemt at reviving the filesystem limit discussion.

2002-12-22 Thread M. Gerards
Quoting "Neal H. Walfield" <[EMAIL PROTECTED]>:

> My idea is to maintain a ~1GB area of "metadata control space."  This
> area, rather than being a one-to-one mapping of memory to backing
> store (as it currently is), would lazily map (via a hash) the metadata
> lazily as it is requested.  (The hash would be used to save the active
> mappings.)  When a page of meta-data is requested, the hash table is
> consulted, if the page is already mapped, the virtual address is
> returned; if not, free space in the 1GB area is allocated.  The
> pager_read_page and pager_write_page routines would consult these
> hashes and read the data from or write the data to the right area of
> the disk as appropriate.

Why does pager_read_page need to consult the hashes? I understand
pager_write_page has to because it needs to disallocate the mapping, but
pager_write_page does not need to modify/use the hashes. Maybe I didn't
understand the libpager interfaces or what you discribed.
 
> My method differs from Thomas' in that I only worry about meta-data.
> Additionally, the mappings are torn down when the Mach thinks it is
> appropriate; not immediately after the region is used or by some other
> internal algorithm.
> 
> The advantage to this algorithm over Roland's is that there would be
> fewer system calls--no need to create and rip down memory objects.
> Also, the startup time would be cheaper as the meta-data is allocated
> lazily rather than a Grand Reorganization when the translator is
> started.

I think there is one problem. I assume most filesystems make assumptions about
the order of the pages. When the filesystem wants to work in a memory area >1
page it wants to have those pages in the same order in memory as they are on
disk. I assume the function that will be used to map has a parameter to
configure the size of this mapping (or how many mappings will be created). It is
possible that some of these pages are already mapped elsewhere. Adding pages to
the hash twice isn't a good thing to do I assume :).

Another thing that might happen is the kernel want to torn down mappings while
they are still used. The change is very low when LRU is used, but IMHO we should
think this will never happen just because of that. This problem can be solved by
using a usage counter or something simular.
 
Is someone working on an implementation of this method or any of the other
methods or did someone plan to do so? I get quite irritated when I see "This
filesystem is out of space, and will now crash.  Bye!" ;)

If noone else will do this I am willing to _try_ to implement Neals method. 

Thanks,
Marco Gerards


___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd