Re: What i would like to see in upcoming kernel releases...

["Albert D. Cahalan" <acahalan@cs.uml.edu>]

>>> 2. Kernel dumps:
>>>    Same applies for this one: kernel dumps have been proven to be
>>>    a very helpful debugging tool.
>> 
>> NetBSD is known for dumping onto the WRONG partition.
> 
> Ahh, but AIX, DEC-Unix, HP-UX, Solaris, Unixware, ... are known not to do
> this.  Are they wrong in implementing it?  Simply because somebody has
> gotten it wrong is no reason to drop this immensely helpful feature.

It is a risk. We have not ever needed crash dumps anyway.

>>> 3. Log-structuered and/or journaled filesystem:
>>>    There has been lots of talk about those two as well.  They are
>>>    a definite must for HA systems.  Despite all the talk about
>>>    reiser-fs and such, the best would be to simply port the BSD stuff
>>>    to Linux (same goes for Berkeley FFS as a replacement of EXT2FS).
>> 
>> Compared to Reiserfs, the BSD stuff sucks. BSD doesn't have a working
>> log-structuered or journaled filesystem, and FFS isn't fast at all.
>> Our ext2 works quite well, though Stephen Tweedie is adding new stuff
>> like journaling, fast B-tree directories, and fast B-tree allocation.
> 
> But the BSD stuff is de-facto standard  and anybody coming from a
> Unix background expect to find some sort of working UFS/FFS on a
> Unix-like system.  Why? Because they know how to work with it.

I don't believe normal people know how to binary edit UFS.
If you just mean comfort, then:

mv mkfs.ext2 mkfs.ufs

Follow up with appropriate /bin/mount hacking.

It would be total stupidity to waste any effort on UFS. It is almost
exactly the same filesystem as ext2, so we don't gain much. Ext2 has
been debugged over a period of about 5 years. If we had UFS tools,
some fool (you?) would install on a UFS partition and lose their data.
Then this person would go to comp.os.linux.* and rant about how
unstable Linux is. It is better to work on filesystems that have the
potential to totally waste traditional UNIX and BSD junk. I'd love to
have XFS support, but we don't have enough documentation. We can have
a nice clone (Reiserfs) though.

>> Only AdvFS (in Digital UNIX) and XFS (in Irix) stand a chance
>> against Reiserfs. Both FFS/UFS and Ext2 are obsolete now.
>> FreeBSD can kiss its ass goodbye.
>
> IMHO AdvFS is a load of shit:  Our University has been using AdvFS together
> with AFS and you would not believe how often the servers have crashed due
> to AdvFS errors.  Only reaction by DEC:  "Well, AdvFS together with AFS
> is not stable on SMP systems."  No wonder they were bought by COMPAQ!

AdvFS may be buggy, but it is not a load of shit. The Linux code
for UFS is buggy - so I guess UFS is a load of shit.

I'll guess performance will be like this:

XFS          Popular for serious web and video servers
Reiserfs     For Linux now; Sun might license it for Solaris
AdvFS        In Digital UNIX; licensed from a 3rd party
...          -- big gap here --
ext2         Linux grew to 20 million on this!
UFS          Old BSD stuff, like ext2 + VAX baggage
HFS          The MacOS isn't bad!
HPFS         Almost the same as HFS
...          -- big gap here --
FAT          Standard low-performance filesystem
JFS          Junk File System
NTFS         Like HPFS, but with journalling to slow it down
LFS          Luser File System

It depends on the benchmark of course. For example, NTFS will beat UFS
and ext2 for filename lookups in large directories. LFS might do well
if all you ever do is write (not read) a small number of huge files.

> Lets face it folks:  LFS/JFS and online compression are two very important
> features to beat the marketing guys telling our bosses to use NT for
> mission critical servers!  No wonder IBM ported AIX' JFS over to Warp 4...

Normal people don't use online compression on mission critical servers!
LFS and JFS really suck.

> And if ReiserFS is too different from the LFS/JFS implemetations currently
> in use in the Unix world, the same applies what i said about UFS/FFS and
> EXT2FS...

Reiserfs is like XFS, but optimized for smaller files than XFS is.
Both totally waste any JFS or LFS.

>>> 4. A comprehensive set of kernel development tools:
>>>    Drop the stuff in scripts and create a stable set of tools (not
>>>    unlike the stuff found on BSD, DEC-Unix or Solaris) which would
>>>    be distributed seperately from the kernel sources (after all this
>>>    stuff does not change very often!).
>
> After thougth a lot about it, the only thing truly missing is a kernel
> debugger capable of inspecting the running kernel.  As far as i know
> gdb vmlinux /proc/kcore  will no quite do this.  Or am i wrong?

You are wrong. You may need to pass a few options to deal with
the slightly abnormal layout, but it does work.

> And what about kernel profiling?  There are tools for this but they
> are hard to find and tend to get lost...

They are only hard to find because they are seldom wanted.

>>> 5. A complete and bug-free console terminal emulation (not the "linux"
>>>    crap, but rather a complete VT220 emulation). Again BSD shows us how
>>>    it is done.
>> 
>> We have one serious scrolling bug that vttest exposes, we don't bother
>> with the obsolete vt52 mode, and we don't implement features that can't
>> be done on VGA hardware. Other than that "linux" is great. BSD sucks.
> 
> Ah, but those features can be done using the framebuffer every Linux port,
> except the one for the x86, uses.

No, not usually. Even when the kernel can switch to 132 column mode,
we don't bother because we have better tools for that. Such junk does
not belong in the kernel.

> And having to explain every newcomer
> why the terminal type of Linux is "linux", even so it is more or less
> just a "vt102" is simply annoying. Not to mention that you either have
> to distribute a "linux" termcap/terminfo entry or rewrite the login
> scripts for root on every system if you are in a heterogenous environment.

If *BSD claims to be a vt102, they lie.
-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/