> But realtime is not about averages, it's about the worst case. The worst
> case for filesystems can be pretty ugly - there are a lot of data
> structures that have to be updated atomically which means there are locks
> that have to be held. There are indirect blocks to write, inodes to
> update, seeks to be made. You might take a look at _Design of the UNIX
> Operating System_ (Bach) to get an idea of what managing a filesystem in a
I was thinking about doing file system coding this summer
(Unified 64 bit Journaling) so, I know that stuff already. :-P
This, along with various SGI realtime video serving papers,
etc...
Communication through email is pretty awkward and doesn't
effectively communicate what I'm thinking about mainly because
I'm not being very careful about writting emails these last
few weeks.
I know about the latency issues and the superficial glance
that I've had with the kernel code gave me the impression that
it didn't keep soft realtime latency issues in mind when it was
first built, which very bad.
I'm reserving my judgement because there are folks that
may have particular fixes to the kernel to allow for this
capability without a serious redesign of the kernel.
It's difficult to picture these change without the need to
seriously reorganize things currently.
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/