Kernel Traffic #62 For 10 Apr 2000

Seth M LaForge felt that Issue #61, Section #11 (21 Mar 2000: Video CD Under Linux) was misleading. As he put it, "in the discussion on VCD you include a list of links from Quang Nguy. However, the links all point to DVD info - DVD is a very different beast from VCD. VCDs are regular CD-ROMs with MPEG-1 encoded movies on them. They're very popular in Asia (usually illegal copies of movies, available for about $2 each on the street), but never caught on (I'm sure pressure from the movie industry has a lot to do with this) in the West. You might want to either point out that DVD and VCD are different or remove the list of links, to avoid confusing readers." That's a good point, Seth. Thanks!

Many thanks go to Antony West, for catching an old bug in the XML of Issue #32, which caused the mailing list stats to render incorrectly; and for reminding me about some runaway <pre> tags in various other issues. Thanks, Antony! Those back-issue bugs can languish for years.

There were 482 different contributors. 236 posted more than once. 184 posted last week too.

Tim Waugh asked, "When is a driver supposed to return 0 from a __setup function? When it can't parse the options? Or when there's a possibility that the option is intended for another driver?" When no one replied for almost a week, he asked, "Is it worth me making a patch to change the behaviour of those drivers that return 0 on error (rather that when the option could be used by another driver) to return 1 instead?" Alan Cox replied, "I've done some of them but not all. So yes." And seven hours later, Russell King said that Alan had sent him the ARM-specific parts of a patch Tim had presumably sent to Alan. Russell affirmed that it would be going into the Linus tree, and thanked Tim heartily.

2. Real Data Corruption Under ext2 In The Stable And Unstable Kernels, And A Fix

Soohoon Lee reported serious data corruption with ext2, in cases of low memory and frequent file creation and deletion operations. He explained that under those conditions, files would spontaneously disappear or be undeletable, the contents of two files would spontaneously switch, and fsck would find inconsistancies in properly unmounted filesystems. He posted a one-line patch to fs/ext2/namei.c to fix it; and Theodore Y. Ts'o confirmed that this was indeed a problem, and not just some local glitch. In response to Soohoon's patch, Ted replied, "This apparently solves the problem for Linux 2.2, but I'd prefer a cleaner patch for Linux 2.3. Enclosed find the patch, which I will be sending on to Linus. I haven't had a chance to backport this patch to Linux 2.2 yet, but it shoudl be relatively simple." He posted his patch, which was much longer than Soohoon's, and there was some talk about other changes to make to fs/ext2/namei.c, if they were going to be changing it at all.

After a bit of private discussion between Jean-Luc Pedneault, Justin Guyett, Urban Widmark, and other unknown assailants; Urban posted a patch for a problem Jean-Luc had been having with via-rhine under 2.3.99-pre3. But he acknowledged being mystified over "why a value that was just written is no longer there, except if you add an if or printk then the value written "stays" written." Jean-Luc replied, "Like you said, it seems that by doing the "if" instruction, the old value doesn't get wiped. The inside loop doesn't ever get run!! It's weird, because it may suggest that the system runs too fast or something.. like if the value wasn't written in memory." He added, "It could be a bug in GCC 2.95.2, a bug that does an optimization wrongly. I'm using this compiler. I haven't tested with egcs-1.1.2 yet (and I don't have GCC 2.7.2.3 compiled at all)."

A couple of hours later, he went on to say, "I'd like to point out that egcs-1.1.2 executed the code fine even with #if 0 (ie. without compiling the additional code). GCC 2.95.2's optimizations breaks the code, at least that's what I think." Urban agreed, but rather than attempt to understand the inscrutable assembly code generated, he posted another patch which tried to do the same thing in a different way. He also suggested generating a smaller, non-kernel test-case to share with the GCC developers, and offered to do it himself if no one else stepped forward. Stephane Casset replied with confirmation that Urban's patch seemed to work.

In the end, Urban concluded the thread by pointing out that the latest GCC snapshot appeared not to have the problem anymore, and he also gave a link to Code Sourcery, a really cool page that would compile any code on the latest snapshot.

An interesting threadlet came out of this interesting discussion about Linux implementation of POSIX threading. In the course of discussion, Ulrich Drepper led into it by saying, "some additional functionality required to implement the correct POSIX threads behaviour is missing." Alvin Starr let himself in for it when he replied, "I am sure that if the next version of the thread library required a set of kernel patches to run effectivly then those patches would end up in the kernel source tree within a version or so." Richard Gooch replied, "Mate, where have you been? The day Linus lets user-space dictate what goes into the kernel is the day hell freezes over. If you want a patch to go into the kernel, you need to convince him it's a good idea. Adding a dependency in user-space, expecting it to "force his hand", will not help. It will probably just piss him off. Or make him laugh."

A bit later, Linus Torvalds made a case about PID sharing and gave some example code. He went on to say, about threading:

Note that the reason the kernel is not POSIX-compliant is:

the POSIX standard is technically stupid. It's much better to use a cleaner fundamental threading model and build on top of that.
things like the above are just so much better and more easily done in user space anyway.

The reason LinuxThreads has a hard time becoming POSIX-compliant is that I refuse to apply stupid patches, and a lot of the patches sent to me have been frankly stupid. They've often implemented pthreads functionality without any actual thought of how it _could_ be done more cleanly with a user/kernel split.

Note that when I started doing clone(), I basically said: "this is how I think threads should be done". I added a few example flags to show the concept, without really having a firm plan on what the final situation would be. Some of those flags got expanded upon (CLONE_PARENT is only the latest addition), while some ended up not being very useful at all (CLONE_PID is basically useless - the only use for it is to start up the original idle threads under SMP, and that code is so specialized anyway that it could basically do the CLONE_PID logic by hand).

There are bound to be more issues. I've seen patches floating around that expand it, and especially in signal handling SOMETHING has to be done. I don't think the "share all signal queues" is the right answer: I suspect the right answer to the signal handling issue is to have a "private" queue (the regular one) along with a separate method of handling "shared" queues and a way to attach to a shared signal queue.

Shared signals are potentially useful outside pure threading models too, and I'm looking for something more generic. I suspect that what I'm looking for is more like a message list, along with some thin compatibility code to make it easy for pthreads emulation that looks like signals..

That's kind of my gripe in general - I think there is a bigger picture than just plain pthreads. Like clone(), let's do this right.

Some earlier discussion of clone() took place in Issue #1, Section #3 (8 Jan 1999: Porting The vfork() Syscall) ; a LinuxThreads announcement appeared in Issue #30, Section #10 (30 Jul 1999: CLONE_PPID Support In LinuxThreads) ; a little bit of clone() history appeared in Issue #32, Section #14 (17 Aug 1999: Threads In Linux) ; some general discussion of threading took place in Issue #34, Section #22 (1 Sep 1999: Some Explanation Of Threading) ; then in Issue #35, Section #13 (7 Sep 1999: CLONE_PID Problems) , Alan Cox said CLONE_PID would be going away in 2.3.x, but according to Linus' statements above, this has not happened yet. A vfork() flamewar (with some good technical goodies) took place in Issue #45, Section #1 (1 Nov 1999: vfork() Discussion And Flame Fest) .

Discussions of development philosophy occur throughout KT, but some specific articles are Issue #4, Section #1 (27 Jan 1999: Philosophy Of The Stable Series) , Issue #5, Section #10 (3 Feb 1999: Philosophy Of Binary-Only Modules) , Issue #9, Section #12 (4 Mar 1999: Philosophy Of Kernel Development) , Issue #18, Section #5 (2 May 1999: Philosophy Of Open Source; Maintainer Conflict) , and Issue #60, Section #8 (15 Mar 2000: Philosophy Of Having Debugging Code In The Kernel) .

Mike A. Harris had a problem with his keyboard repeat rate slowing down when switching a shared keyboard between two machines. In the course of discussion, it came out that if there was any loss of power to the keyboard, this would be the inevitable result. However, at some point Andrew Morton mentioned:

Russell King says he has a patch which does autorepeat in s/w. This is most definitely the best way. I did this in an OS many years ago - took one look at the XT keyboard specs and said "nope".

It's very easy to do. Just a little state machine which squirts out the most recent 'make' code and stops doing that when it sees a 'break'. It also gives you infinite control over the autorepeat speed, although topping out at HZ seems reasonable.

Russell replied, "I'll be sorting it out later today when I do my next set of patches for Linus et al."

Rik van Riel posted a patch against 2.3.99pre3, to take some code out from the interior of a while loop in kswapd; and added, "I wonder who sent the brown-paper-bag patch with the superfluous while loop to Linus ..." Kanoj Sarcar replied red handed, "That would be me ..." He asked what Rik's patch actually fixed, aside from the while loop, which appeared cosmetic. Rik replied that ditching the loop was actually a serious fix by itself. Without his patch, he reported that kswapd used between 50% and 70% of the CPU in a particular workload. With his patch, it used between 3% and 5% of the CPU. Kanoj pointed out that the while loop had been in the kernel since way back in 2.3.43, and Linus Torvalds, replying elsewhere, said, "you're definitely right that this is not a new bug introduced by you, Kanoj - this seems to be just a thinko that has been there for a long long time. And I suspect I may have been the original perpetrator of the crime." Kanoj let out a facetious sigh of relief that he hadn't introduced the bug, and they discussed some of the ins and outs of Rik's patch. It turned out that, as Linus described the situation prior to Rik's patch:

What happens is that kswapd is only woken up when needed, so most of the time it is sleeping. It's only when it is woken up and when it has done its work when the loop turns into a CPU-burner, but it can easily mean that kswapd will just spend CPU time for no good reason until its time-slice is exhausted.

So think of the bug as "kswapd will waste the final part of its timeslice doing nothing useful".

Elsewhere, under the Subject: [RFT] balancing patch, Kanoj posted a separate patch to ease kswapd's CPU usage. Mark Hahn didn't notice any improvement, and Christoph Rohland noticed various Out Of Memory breakages when the system started to use swap. However, Rik reported:

I'm now testing Kanoj' balancing patch together with my kswapd infinite-loop-removal patch. The system seems to work quite well, I haven't seen any big strangeness in the VM load (the variance in the amount of free memory is a bit bigger, naturally, but that's to be expected) and interactive performance from the console seems unaffected.

It would be nice if a few more people tested the combination of 2.3.99-pre3 with Kanoj' balancing patch and my infinite-loop- removal patch ... (because YMMV)

Folks, there is a cleanup of mount-related stuff underway. Right now the patch seems to be usable for testing.

It doesn't include pieces in nfsd and auotfs*, so these simply wont compile, but it should <knocking the wood> work with everything else.

It allows

to mount the same filesystem several times. Yup, ext2 included. No cache coherency problems - all instances share the dentry tree.
to work with shmfs without mounting it.
to do explicit loopback mount. As in

# mount -t bind /usr/X11R6 /mnt # ls /mnt bin doc include lib man share # cd /mnt # ls .. bin dev home lost+found mnt proc sbin usr boot etc lib misc opt root tmp var

(IOW, unlike the usage of symlinks it gives correct behaviour on ..)
to mark filesystem type as 'single'. One superblock will be created when you initialize the driver, all later mounts of that type will be aliases to that one. IOW, we can start storing procfs immediately in dcache - just a normal tree. Moreover, kernel can access that tree even if it's not mounted by user. That's how the shmfs stuff is done. Oh, and all instances will share the device number, so you can create a thousand chroot jails, mount devpts on each and spend 1 (one) anonymous device. Ditto for procfs, etc.

Patch (against 2.3.99-pre3) lives on ftp://ftp.math.psu.edu/pub/viro/mount-patch-4.

Folks, give it a try. There may be bugs. I think that it's cleaner than the old code, but don't let it play with critical data. Bug reports are more than welcome, indeed. Another thing that is _very_ welcome is a discussion of the export rules in situation when filesystems on server may be mounted several times (as well as the current implementation - I'ld really like to hear comments on it, in particular on the exp_parent(). It's either buggy and doesn't what it is supposed to do or contains seriously superfluous code). General comments on the patch are also welcome, indeed.

Fixed

Tulip hang on rmmod (fixed in .51 ?)
Incredibly slow loopback tcp bug (believed fixed about 2.3.48)
COMX series WAN now merged
VM needs rebalancing or we have a bad leak
SHM works chroot
SHM back compatibility
Intel i960 problems with I2O

In Progress

Merge the network fixes (DaveM)
Merge 2.2.15 changes (Alan)
Get RAID 0.90 in (Ingo)

Fix Exists But Isnt Merged

Signals leak kernel memory (security)
msync fails on NFS
Semaphore races
Sempahore memory leak
Exploitable leak in file locking
Symbol clashes and other mess from _three_ copies of zlib!
Shared memory changes change the API breaking applications (eg gimp)
Merge the RIO driver (probably do post 2.4.0 as it is large)
S/390 Merge (merged in AC tree)
via rhine oopses under load ?
1.07 AMI MegaRAID
PCI buffer overruns
SCSI generic driver crashes controllers (need to pass PCI_DIR_UNKNOWN..)
Finish softnet driver port over and cleanups

To Do

Restore O_SYNC functionality
Fix eth= command line
Trace numerous random crashes in the inode cache
Fix Space.c duplicate string/write to constants
VM kswapd has some serious problems
vmalloc(GFP_DMA) is needed for DMA drivers
put_user appears to be broken for i386 machines
Fix module remove race bug (mostly done - Al Viro)
Test other file systems on write
Directory race fix for UFS
Audit all char and block drivers to ensure they are safe with the 2.3 locking - a lot of them are not especially on the open() path.
Stick lock_kernel() calls around driver with issues to hard to fix nicely for 2.4 itself
PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)
Use PCI DMA by default in IDE is unsafe (must not do so on via VPx x<3)
Use PCI DMA 'lost interrupt' problem with some hw [which ?]
Crashes on boot on some Compaqs ?
pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32
usbfs hangs on mount sometimes
Loopback fs hangs
Problems with ip autoconfig according to Zaitcev
Still some SHM bug reports
Any user can crash FAT fs code with ftruncate

To Do But Non Showstopper

Make syncppp use new ppp code
Finish 64bit vfs merges (lockf64 and friends missing)
NCR5380 isnt smp safe
DMFE is not SMP safe
ACPI hangs on boot for some systems
Get the Emu10K merged
Finish I2O merge
Go through as 2.4pre kicks in and figure what we should mark obsolete for the final 2.4
Per Process rtsigio limit
Fix SPX socket code
Boot hangs on a range of Dell docking stations (Latitude)
Port SGI VisWS to 2.3.x or mark obsolete
HFS is still broken
iget abuse in knfsd
Mark NTFS as obsolete
Paride seems to need fixes for the block changes yet
PIII FXSAVE/FXRESTORE support
Some people report 2.3.x serial problems
AIC7xxx doesnt work non PCI ?
USB hangs on APM suspend on some machines
PCMCIA crashes on unloading pci_socket
DEFXX driver appears broken
ISAPnP IRQ handling failing on SB1000 + resource handling bug

Compatibility Errors
Probably Post 2.4

per super block write_super needs an async flag
addres_space needs a VM pressure/flush callback
per file_op rw_kiovec
enhanced disk statistics
AFFS fixups
UMSDOS fixups resync

Drivers In 2.2 not 2.4

Lan Media WAN

To Check

Truncate races (Debian apt shows it nicely) [done ? - all but Coda]
Elevator and block handling queue change errors are all sorted
Check O_APPEND atomicity bug fixing is complete
Make sure all drivers return 1 from their __setup functions
Protection on isize (sct) [Al Viro mostly done]
Mikulas claims we need to fix the getblk/mark_buffer_uptodate thing for 2.3.x as well
Network block device seems broken by block device changes
Fbcon races
Fix all remaining PCI code to use new resources and enable_Device
VFS?VM - mmap/write deadlock
rw sempahores on page faults (mmap_sem)
kiobuf seperate lock functions/bounce/page_address fixes
Fix routing by fwmark
Some FB drivers check the A000 area and find it busy then bomb out
rw semaphores on inodes to fix read/truncate races ? [Probably fixed]
Not all device drivers are safe now the write inode lock isnt taken on write
File locking needs checking for races
Multiwrite IDE breaks on a disk error
AFFS doesn't work on current page cache
ACPI/APM suspend issue

Wakko Warner replied to item 4.13 (PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)), with, "Fixed for me. Since yenta doesn't probe irq12, it doesn't cause me any lockups."

Alan Cox announced a patch against 2.3.99pre3, so people could keep up with him in their debugging expeditions, but Arjan van de Ven noticed that it wasn't on any of the kernel.org mirrors. Alan replied, "It does appear not to be mirroring right. I've put a copy on ftp.linux.org.uk:/pub/linux/alan/" . H. Peter Anvin offered, "Please report broken kernel.org mirrors **including IP address** to ftpadmin@kernel.org as soon as you can tell, please." James H. Cloos Jr. also explained:

The notify from ftpadmin to lka-change didn't go out until Tue, 28 Mar 2000 15:43:24 -0800 or about 70 minutes after Alan's note (quoted above), or about six hours after Alan's initial announcement....

I'm sure most of us rsync only once or twice a day from cron(8), plus whenever lka-change mail arrives, hense the delay.

Rik van Riel posted a patch against 2.3.99, to implement a low overhead fair process scheduler. As he explained in the code comments, "It works by handing out CPU time like we do at the normal recalculation. The catch is that we move the list head (where the for_each_task() loop starts) to _after_ the first task where we ran out of quota. This means that if a user has too many runnable processes, his tasks will get extra CPU time here in turns." But he reported to the list:

Unfortunately it hangs on taking locks in the recalculation code :(

I'm somewhat amazed by why it hangs and interested in any explanations...

Jun Sun gave his tentative opinion, "Interrupt handlers sometimes call kernel functions that would require a lock on tasklist_lock. If that interrupt happens during the time you hold write lock on tasklist_lock, a deadlock would happen." He suggested using write_lock_irq() to fix it, and added, "BTW, I really think interrupt handlers acquiring the same locks which can be acquired by processes is a *BIG* problem in Linux." Andrew Morton asked why Jun though this, and Jun replied, "Linus told me so. I believe him. :-)" On a more technical note, he added, "I did sniff around the source code and spotted a couple of places where locks COULD be acquired by ISRs, but I never did a RUN-TIME check to catch this situation," and went on to say:

I believe the problem here is that Linux does not have a CLEAR notion and separation of task-context code and interrupt-context code.

Imagine if a kernel function needs to read task list, then it must acquire a read lock on tasklist_lock. However, the function might be called from both process and ISR, then we will have the ISR acquiring lock problem.

I don't know if this has been a problem to Linux in the past. I am relatively new to Linux kernel.

There was no reply to this, but Rik, replying to Jun's suggested write_lock_irq(), posted a new patch, and said:

Indeed, that was the problem. I was lucky to get a few good traces by the NMI oopser that identified this problem. Now things are fixed.

The new patch is attached, for adventurous users. I'm testing it on my SMP system now.

George Bonser noticed in the ip-route cref document, a description of the 'equalize' modifier: "allow packet by packet randomization on multipath routes. Without this modifier route will be frozen to one selected nexthop, so that load splitting will occur only on per-flow base." The same document said that the kernel had to be patched to make use of this feature. George asked if this was still the case, or if 'equalize' had been integrated into the main kernel sources. Andi Kleen and Guus Sliepen (author of the patch) replied that it had not been integrated. Guus gave a pointer to the patch, and explained:

It works indeed by throwing out cache entries every time they have been used. This works for up to at least 20 Mbit/s of traffic, but not for 400 Mbit/s (both cases have been tried, the former works fine, the latter does not). You can try it if you like.

Route based load balancing does have certain advantages over bonding devices. But it's really hard to implement in a clean way in current kernels. I'd rather see the complete networking code being a module, and those who want to use different routing/firewalling/scheduling schemes can load (or even create their own) different modules. The current code is (to my eye) just a messy bunch of hooks and checks.

He added that he'd propose this for 2.5 when the time came. There was no reply to this, but Andi's reply to the original post, was that equalization on the routing cache layer was too slow or not fine-grained enough, for inclusion in the main sources. Someone asked for more explanation, and Andi replied:

Linux has a routing cache that caches routing table lookups. This is called the destination cache. A destination cache entry is tied to a specific destination, which means only a single neighbour on a multipath route. To use multipath routing for load balancing requires dropping the destination entry after every use, so that another neighbour in the multipath could be looked up (the destination cache knows nothing about multipaths, that is all encapsulated in the FIB or routing table)

Dropping them all the time does not work well and is slow. It is also not finegrained enough (because the decision occurs to early) to get an even load balancing

Multipath routing is only useful for failover when a device is down in Linux.

For load balancing you can use the existing eql, teql and bonding devices, which work at a lower layer and avoid these problems.

Alexey Kuznetsov was critical of this explanation, and said that multipath routing worked "perfectly when you need to split load on servers talking to enough large number of clients. Any http server is good example." He added that Andi's suggestion of the existing eql, teql and bonding devices, would introcude "even worse problem of strong tcp reordering. Actually, experiments show that load balancing works only in the situations, when congestion window is bounded by 3 packets. If it is not made artificially, it occurs automatically on each connection after some amount of excessive retransmissions. Total single TCP connection throughput is never better in this case. Actually, it hints to the thought that "true load blalancing" has to involve tracking connections and avoiding reordering TCP packets." There was no reply to this, but there was a bit of implementation discussion elsewhere, along the lines of Andi's explanations.

Dave Jones posted several patches to update AFFS, although he proclaimed loudly that this code was possibly dangerous and should not be used without extensive backups. At one point, he added, "I'm coding without tools to test this, so I need help from the people who are going to be using this.. I'd also appreciate feedback from other filesys/vfs guys about anything in this patch that just 'doesn't look right' I've gone from knowing nothing about fs/VFS to this diff in four days, and now my head hurts. I wouldn't be at all surprised if I've done _something_ wrong somewhere." To Dave's discussion of ongoing work and problems, Alexander Viro replied:

real problems with AFFS are different. I'll bring the pre-patch I've done back in September from backups tomorrow and then you'll get more detailed description, but right now I can recall the following:

AFFS handles links horribly. It has pseudo-inodes for all links and they point to the real one. Unfortunately, that "real" inode _must_ belong to some directory. Which means that if you create a link to file and remove the original link you are in for pain. You can't just remove the original entry from its hash chain. So the bloody thing finds some other link, moves the name into original one, inserts the original into hash chain of the other and kills other. It means that unlink() in one directory may reshuffle another. And you've got _no_ protection by i_sem on another directory - any attempt to get it will lead to easy deadlocks. Consequence: _easy_ races.
You have to account for situations when link() and unlink() race with each other. Again, not done in the current code.
Links on directories easily kill VFS. Don't.
Since some operations (e.g. rename) involve a _lot_ of hash chains walking and pointers switching - beware of the failure modes when you abort in the middle of modification. It may easily leave you with fucked up filesystem.

It's a lot of crap to fix and I gave up on that when I got more pressing things to do. I can pass you the patch along with notes. I can remove the swearwords - you will reinsert them as soon as you'll play with this beast yourself.

The bottom line: AFFS design is a festering pile of dung and attempts to make it look like UNIX filesystem only made it uglier. Judging by dejanews search, AmigaOS itself doesn't handle it well. Hell knows what had stopped them from replacing it with decent filesystem - with the thing outside of kernel it wasn't that hard to do... Damnit, FAT is not so braindead compared to that abortion.

Matthias Andree added his sentiments, "These problems you mention have been persisting in AmigaOS for years ever since links had been introduced with AmigaOS 2, PLUS, AmigaOS shell commands have had bugs so that only the GNU ported fileutils along with the FileSystem-based (as opposed to dos.library based) ixemul.library could get you rid of directory symlinks; this is partly because links had originally not been present in AmigaOS 1.x, partly because they fucked things up really bad." He went on:

There are some commercial (AFS/PFS - some versions of these are also fucked beyond repair) and at least to freeware (SFS, Berkeley FFS Amiga port) filesystems, I never checked them for completeness or stability, though. Amiga users seem to be quite satisfied with SFS which is claimed to be journalling.

The Dircache (DCFS) option of OFS/FFS (DOS\4 and DOS\5) are also claimed to be fucked somewhat and slow things down for disks with low random access times such as hard disks.

If you consider seriously revamping the AFFS support, I strongly urge to get hold of Ralph Babel's "The Amiga Guru Book" which contains carefully collected information on DOS internals, while you will still need the Amiga Developer's CD for information on Dircache.

I've given up almost all my AmigaOS activities for the sake of Unix, AmigaOS has given me too much grief with all its troubles, it had just shoot one filesystem beyond recovery (into crash-on-access state) once again.

And since that stuff is so severely fucked, I suggest marking write support EXPERIMENTAL and add a kernel compile-time option for that.

Dave also replied to Alexander's harsh critique, adding, "Which is probably why someone came along and wrote PFS (Professional File System) for it, and made a whole load of money from it." He asked, "Anyone know if any tech-documentation on this exists? That may be an interesting filesystem to hack on when I'm done with AFFS.." Nicholai didn't know of anything for PFS, but he added, "Smart File System (SFS) on the other hand is a free (as in beer) filesystem with good technical documentation. It has gained ground in the amiga community lately." He gave a pointer to an SFS page.

But Nicholai Benalal came somewhat to AmigaOS' defense in response to Alexander's stark depiction, saying, "AFFS works allright under AmigaOS. It has limitations but generally it's ok. Still, a lot of people use other filesystems for AmigaOS but there are no Linux drivers for these. So the best way to transfer files between the Amiga side and Linux is still the buggy Linux affs driver :-)" A lot of people pointed out that the 'tar' command might be a decent alternative. Matthias added that lack of Linux drivers for the other filesystems might have something to do with the lack of available sources for those primarily commercial filesystems. He also disagreed with Nicholai's assertion that AFFS worked passably under AmigaOS. He expressed, "It blows itself off its very feet when crashing at the wrong time and leaving a system behind that's corrupted beyond repair. This is happening all over the place every now and then."

Rask Ingemann Lambertsen replied, "AFFS is as good (or bad) as ext2 in this regard." But Matthias and Alexander both objected to this. Alexander said, "It is not. You need much more atomic operations to get from one valid state of filesystem to another. And I mean _much_ more - as minimum twice. Data structure is designed by complete loonie - just look at it and write down the worst-case set of modifications to be done upon rename(). Pay attention to the size of critical part - _some_ steps can be performed without corrupting the structure if you fail after them, but there is a nice lump that should be taken together or not at all. Now, do the same for FFS (_real_ one, designed by sane people). Or its descendants - ext2, ufs... Compare the results." And Matthias also said, "AFFS is much worse. It needs reordering hash chains, touching several and so on even on a single rename. If your machine crashes before all blocks have been written, you're in trouble, since tools that handle this do not come with AmigaOS. I've NEVER lost so much data with ext2 because of corruption as I recently lost with affs (on AmigaOS). AFFS is fine only as long as you don't touch anything."

Dragan Stancevic posted a patch to the non-Intel eepro100 driver, to provide more detailed information about installed devices, and in the course of discussion, Alan Cox mentioned, "I've had some discussion with intel about fixing the licensing for the eepro100 driver they released so that we can merge the two (they have support for more boards, ucode for interrupt mitigation, errata workarounds and portability and locking flaws." He added, "I have a positive answer I dont quite understand 8) from the Intel lawyers." Dragon replied, "I was not aware that intel is reconsidering their license... Did they give you any time frames to when the intel driver might be release under a more compatible license?" And Alan Concluded, "Basically once I finish talking to the lawyer. I've just not had time and I'll be busy next week too."

Someone purporting to be Linus Torvalds announced that he'd partnered with Microsoft and would be selling Linux from now on. Everyone rolled their eyes, but the interesting part is how quickly the identity of the poster was established. Within a day his name and various personal details were known and published. It looked as though a serious manhunt would soon be under way, until Michael Talbot-Wilson said, "Hey, guys. Enough, huh? He intentionally made it clear enough that it was a joke. Fun for a couple of minutes, right?"

Continuing from last week in Issue #61, Section #15 (22 Mar 2000: iproute2 And netfilter HOWTO) , Bert Hubert announced:

3 new HOWTOs:

Linux 2.4 Advanced Routing & Traffic Shaping HOWTO http://www.ds9a.nl/2.4Routing

Do interesting stuff with netfilter, ip, tc and other tools. Already quite long and considered useful by a lot of people. Cooperative project with 4 authors working together via CVS
Linux 2.4 Networking http://www.ds9a.nl/2.4Networking

iproute2 HOWTO which also tries to impart understanding of basic Linux networking. Still in its very early stages and desperately needs more authors.
Linux Logical Volume Manager HOWTO http://www.ds9a.nl/lvm-howto

A very hands on HOWTO about LVM. In its early stages as well but already quite useful - progressing rapidly.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	21 Mar 2000 - 27 Mar 2000	(4 posts)	Driver Return Values
2.	21 Mar 2000 - 27 Mar 2000	(4 posts)	Real Data Corruption Under ext2 In The Stable And Unstable Kernels, And A Fix
3.	24 Mar 2000 - 28 Mar 2000	(9 posts)	GCC 2.95.2 Bug; Workaround; And Fix
4.	24 Mar 2000 - 30 Mar 2000	(97 posts)	POSIX Threads; Philosophy Of Kernel Development
5.	24 Mar 2000 - 1 Apr 2000	(17 posts)	Keyboard Repeat Rate
6.	26 Mar 2000 - 27 Mar 2000	(11 posts)	kswapd Speedups
7.	26 Mar 2000 - 29 Mar 2000	(4 posts)	Mount Code Cleanup
8.	28 Mar 2000 - 30 Mar 2000	(21 posts)	Things To Do Before 2.4: Saga Continues
9.	28 Mar 2000 - 29 Mar 2000	(6 posts)	Problems With kernel.org Mirrors
10.	28 Mar 2000 - 29 Mar 2000	(5 posts)	New Scheduler Code; Locking Issues
11.	28 Mar 2000 - 30 Mar 2000	(12 posts)	Network Load Balancing
12.	29 Mar 2000 - 3 Apr 2000	(37 posts)	AFFS Support And Discussion
13.	30 Mar 2000 - 31 Mar 2000	(14 posts)	Intel eepro100 Driver To Be GPL-Compatible?
14.	1 Apr 2000 - 2 Apr 2000	(21 posts)	This Year's April Fool's Joke
15.	2 Apr 2000	(1 post)	New Networking HOWTOs And LVM HOWTO

Kernel Traffic #62 For 10 Apr 2000

By Zack Brown