Subject: Re: kernel oops when writing to hfs filesystem, + varous other problems
From: Timothy A. Seufert (tas@mindspring.com)
Date: Sat Mar 02 2002 - 04:48:26 MST
At 5:00 PM +1100 3/2/02, Ben Stanley wrote:
>Timothy,
>
>Thanks for taking the time to answer my queries. I had figured out some of
>them by spending a *lot* of time reading newsgroups, but it was helpful to
>have your reply. I am now planning the system differently. I'm disappointed
>that I won't be immune to filesystem corruption with mol...
I just realized the better option for you is to turn the problem on
its head, by storing critical files in the Linux file system. The
MOL session can access any FS mounted in Linux through a sort of
roundabout method. You set up MOL networking with a virtual ethernet
device so the MacOS session and Linux can send packets to each other,
and you start the netatalk service (AppleShare file server) on Linux
to serve the directory you want to use for shared space. It's then
possible to mount the netatalk-served folder in the MacOS session.
The layering and virtual network involved means that this is not as
fast as the native disk support in MOL, but it's still plenty fast
for most purposes. And when the MacOS session dies, it certainly
won't do anything bad to the Linux ext2 file system.
You'll still have to have a partition for MacOS to boot from, though.
>BTW, can I use the hfsutils on a partition while mol is using it, or must
>I quit mol first?
Yes and no. You probably can get away with it in a large number of
cases, but it's playing with fire. Linux and MacOS each have their
own disk cache, and each assumes it is the only OS accessing the
partition. When you attempt to read something from one side and the
other side has dirty buffers that have yet to be flushed to disk, you
can run into problems.
Multiple writers can get to be really ugly too -- the HFS/HFS+ B*Tree
directory structure needs to be rebalanced on each node insertion /
deletion AFAIK, and it could get scrambled badly if two writers try
to rebalance the tree at the same time.
But I suspect that if you can get the netatalk thing working, you
won't want to do that anyways.
>Regarding hfs, I'm encouraging some lecturers at my uni to set hfs+ as a
>project for our 3rd year project groups. This may also include cleaning
>up hfs... but, don't don't count your chickens before they've hatched.
Ideally one would make a single file system driver that knows both.
As far as I can tell, that's how Darwin (MacOS X) works. A lot of
the stuff is similar enough between the two that it's very possible
to just treat HFS as a subset of HFS+, or something like that.
>Said lecturer first has to convince a project group that a filesystem is
>'sexy' enough to take on instead of some GUI project, and the group that
>takes it on may not get anywhere... but that's what happens when students
>write code. Maybe something good could come of it.
Frankly I wouldn't expect anything useable to come out of it, but you
never know.
I'm not running down students, BTW. It's just that HFS is a rather
complex FS, and the Linux VFS interface is, like most Linux kernel
internals, a constantly moving target with little (if any) current
documentation. And last but not least, writing core kernel code for
a SMP operating system is Difficult, especially the relatively
complicated stuff like file system code. If the documentation were
excellent, it could be a challenging project for a very smart 3rd
year student -- but since the documentation practically doesn't exist
they'd probably just flounder trying to figure out what they need to
do instead of getting real work done.
(That's just sort of my personal guesstimate from relatively recent
experience _being_ a 3rd year undergraduate, and my occasional
browsings through Linux kernel source code. I personally would need
a nice chunk of time to figure out what I was doing if I were asked
to do this.)
One way to make it a more practical project is to do a read-only
implementation first, then tackle writing only if it looks like
there's enough time left in the quarter / semester / year / whatever.
My understanding is that the Linux VFS interface is designed to make
implementation of a simple read-only FS relatively easy.
-- Tim Seufert
This archive was generated by hypermail 2a24 : Sat Mar 02 2002 - 05:03:44 MST