From: Will Dyson <will_dyson@po...> - 2001-09-06 10:02:53
Over the past week or so, I've been using UML to help me debug a
filesystem I'm working on (BeFS, native fs on BeOS, if anyone is
One problem that has continued to haunt me for some time was that I was
getting bogus data back from bread() when trying to read some inodes. I
confirmed that the data was bogus by reading the same block from the
device with dd (not under uml). Bread() was not returning an error, but
I was getting errors printed to the console like this:
do_io - lseek failed : errno = 22
The error is printed from do_io() ubd_user.c. I looked at the code
around the error message, but was not enlightened. It remained a mystery
for some time, because trying to set a breakpoint in do_io() cause the
uml kernel to hang when I continue.
Now, before anyone gets too worried, I've figured it out. I took the
time today to systematicly figure out which blocks would cause this
error when read. It turns out that blocks larger than 2^21 cause it.
With 1k blocks. I hit myself on the head once I realized that I was just
hitting the 2GB file size limit in the host kernel.
I'll use a smaller filesystem for testing from now on, but I've been
wondering why errors that occurs in do_io aren't propigated up to cause
errors at higher levels of code.
I've taken a closer look at the ubd driver code. And I see that none of
the code that calls it catches its return value. Is there a good reason
why this isn't done? If I wanted to take a shot at fixing this, would it
be a reasonable idea to set the io_thread_req to an invalid state when
do_io() returns -1? Where does the ubd driver return control to user space?
Get latest updates about Open Source Projects, Conferences and News.