Subject: Re: kernel oops when writing to hfs filesystem, + varous other problems
From: Ben Stanley (bds02@uow.edu.au)
Date: Sun Mar 03 2002 - 00:02:48 MST
Timothy A. Seufert wrote:
> 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.
This sounds interesting... I had previously tried to get MacOS to talk
to outside machines without success, but that turned out to be a problem
with the other Mac I was trying to talk to. I have now fixed that, and I
can now see the other machine in the chooser from inside mol.
So I guess I'll have to figure out how to set up a netatalk server
now... I think I've done it before; it's just fiddly.
Now, I still have a problem with CDRoms... How can I read an hfs+ CDROM
from inside mol? At the moment, I have to reboot into MacOS. I tried
starting Drive Setup on MacOS, but it won't scan the SCSI bus (mol
prints something about an un-implemented gestalt when you try). (You can
then manually mount any volumes that it finds.)
And one last problem: Is there any way that I can run mol at a custom
screen size (ie. slightly smaller than the full screen size)? I can
re-size the screen using the control strip, but that only gives me the
choice of standard screen sizes.
> 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.
Sounds like you'd end up with a lot of if statements... sometimes it's
better to just fork it and be done with it. Perhaps a study of the
Darwin code is in order before deciding to do this.
> I'm not running down students, BTW. It's just that HFS is a rather
> complex FS,
Funny... I had another opinion from a seasoned coder that it shouldn't
be very hard... but, I guess that's the difference between relative
newbies in the area and someone who's already coded a compressed audio
decoder...
> 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.
Our projects work in groups of 4 or 5 students. It is just as much an
exercise in learning to operate in a group as anything else. I would
expect it to take them half of the year to find their feet, and a few
more months to punch something out... There is a full tech spec of HFS+
as a TechNote on Apple's web site, but I was unaware of the lack of
documentation on VFS. So far I have been reading Jonathan Corbett's most
useful (GPL'd) book "Linux Device Drivers", which has been quite
enlightening. But I don't imagine it will discuss much to do with the
details of filesystems.
I would imagine the group would probably work with a stable kernel so
that they could get their work done without distraction and port it to
2.5 towards the end, but if there was documentation in the 2.5 series
which was relevant to the stable 2.4 code that would be useful.
> (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.
Even parts of hfs need to be cleaned up / debugged / finished off. For
example, we need an fsck for hfs. Even if the project group only did
some of these tasks, that would be useful.
I suppose that someone writing an fsck might find it useful to collect
images of damaged filesystems (preferably small), so as to verify that
the program can detect and fix the damage. And I know that there is a
difference between Norton's Disk Tools and Apple's Disk First Aid.
I presume that linux can mount .img files as a filesystem? That would be
really useful for testing. And I can see that User Mode Linux would
allow for a real speedup in the development process, because you can
then run gdb on the kernel, and bugs in the code under development don't
jeapordise the stability of the underlying system. And the preemptive
kernel patch makes a single cpu machine behave much more like smp, so
that should be good for testing.
Anyway, thanks for your input.
Ben.
This archive was generated by hypermail 2a24 : Sun Mar 03 2002 - 00:15:08 MST