[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Back page
All in one big page

See also: last week's Back page page.

Linux Links of the Week


When not to be good!. Need one final chuckle for the Christmas season? Check out this joke from Verlag Heinz Heise GmbH. Here is a translation in advance that you will need:

Have you all been good?

No!

Never!

Not at all!

Not a bit good!

Thanks to Fred Mobach for sending this in.

Section Editor: Forrest Cook


January 4, 2001

   

 

This week in history


Two years ago (January 7, 1999 LWN): The 2.2 Linux kernel pre-release series began; the stable release was pushing towards version 2.0.37. The Linux Kernel Archive mirror system was started with two mirror sites. There are now hundreds of Linux kernel archive mirror sites all around the world.

Numerous people predicted that Open Source software would be big in 1999; these predictions turned out to be accurate.

Info World speculated that "Linux will become just another Unix. The Internet lost its charm when big business discovered it. The same will happen with Linux. Linux will wipe out SCO and Unixware and gain ground against NT, but will lose its soul in the process". Well, they got the SCO part right, but Linux continues to have almost as much soul as James Brown.

Red Hat was getting lots of attention with its corporate expansion and potential of being a threat to the Microsoft empire.

The first issue of the Debian Weekly News came on-line; that project is still going strong.

Aladdin Ghostscript was released under a GPL license.

One year ago (January 6, 2000 LWN): Linux survived the Y2K bug with a few minor bugs here and there; so did the rest of the world. Several Linux distribution vendors came out with some additional Y2K bug fixes.

The cracking of the DVD encryption format was big news; Eric Raymond wrote a letter to LWN entitled DVDCA and the Big Lie.

The stable kernel was version 2.2.14, which was a bit long in coming. The development kernel was version 2.3.35. With Y2K concerns out of the way, the Unix Year 2038 bugs were beginning to get a look.

The first of many SEUL/edu Linux in Education reports came out; this group continues to produce good information concerning Linux in the schools.

Numerous commercial entities announced the open-sourcing of projects; among them were InterBase from Inprise, the CompactPCI networking package from MontaVista, and several device drivers.

VA Linux introduced its now-highly-successful SourceForge site which provided a home to many open-source projects. Apple announced the roll-out of its Mac OS X, a Free BSD based platform.

 
   

 

Letters to the editor


Letters to the editor should be sent to letters@lwn.net. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
 
   
Date: Thu, 28 Dec 2000 23:06:22 -0700
From: Eric B <ewbish@theriver.com>
To: letters@lwn.net
Subject: MSNBC Thinks Microsoft is the underdog!

In the article: http://www.msnbc.com/news/508942.asp on MSNBC's website
the author states the following in regards to his top tech predictions
for 2001:  

 		   "Microsoft comeback: The Redmond giant
                   could become the thought leader on the Web as
                   it was for PCs. Microsoft will finally have most
                   of its .Net architecture in place next spring.
                   Based on what I've seen, it will have all the parts
                   in place for a viable platform for the
                   next-generation Web. It may take 12 to 18
                   months, but don't be surprised to see Microsoft
                   take the leadership role away from Sun, Oracle
                   and the Linux crowd. Click for more."

Apparently we already won and nobody told us.  I guess now we are
fighting to stay on top!
Eric Bueschel
-- 
Windows:  A 32 bit shell for a 16 bit operating system, originally
written for
an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand 1
bit of
competition!
   
From: Anton Ertl <anton@a0.complang.tuwien.ac.at>
Subject: Yet more on Elevator algorithms and write ordering
To: letters@lwn.net
Date: Fri, 29 Dec 2000 12:54:25 +0100 (MET)

Matt Dillon writes:
>I'm afraid there is considerable confusion over write ordering in a
>filesystem.  The confusion stems from an assumption that dependant
>operations are queued to the disk device all together.

No, there is no such assumption involved.

>This assumption
>is not true of FFS with softupdates.  FFS with softupdates turned on will
>queue all *NON* dependant buffers to disk all at once and doesn't care
>in the least whether the kernel, the disk device, or the physical disk
>itself reorders the writes.  Dependant buffers are not queued until
>non-dependant buffers have completed their I/O's.

I would say "buffers they depend on" instead of "non-dependent
buffers", but otherwise, yes, that's how file systems currently try to
enforce write ordering constraints.

The problem is: how do they know that the I/O for a buffer is
completed?  A disk with write-caching enabled happily reports that it
has completed the I/O for a block when it has the block in its RAM
cache.  The disk driver and buffer cache then report I/O completion to
the file system, which submits the next batch of blocks.

These blocks may arrive at the disk while much of the earlier batch is
still in the cache, and then the reordering optimization of the disk
may write the blocks in an order that results in a file system
inconsitency.

You can see this effect with
http://www.complang.tuwien.ac.at/anton/hdtest/.  With write caching
disabled on the disk, the blocks are written in-order (i.e., the Linux
buffer cache does not reorder these accesses).  With write caching
enabled on the disk, the two disks I tested delayed writing one block
for as long as I tested (several seconds).  I wrote this test in order
to check some assumptions necessary for a log-structured file system I
was involved with.  I was not pleased with the result.

- anton


   
Date: Fri, 29 Dec 2000 10:02:45 -0800 (PST)
From: Matt Dillon <dillon@earth.backplane.com>
To: Anton Ertl <anton@a0.complang.tuwien.ac.at>
Subject: Re: Yet more on Elevator algorithms and write ordering

:I would say "buffers they depend on" instead of "non-dependent
:buffers", but otherwise, yes, that's how file systems currently try to
:enforce write ordering constraints.
:
:The problem is: how do they know that the I/O for a buffer is
:completed?  A disk with write-caching enabled happily reports that it
:has completed the I/O for a block when it has the block in its RAM
:cache.  The disk driver and buffer cache then report I/O completion to
:the file system, which submits the next batch of blocks.
:
:These blocks may arrive at the disk while much of the earlier batch is
:still in the cache, and then the reordering optimization of the disk
:may write the blocks in an order that results in a file system
:inconsitency.
:
:You can see this effect with
:http://www.complang.tuwien.ac.at/anton/hdtest/.  With write caching
:disabled on the disk, the blocks are written in-order (i.e., the Linux
:buffer cache does not reorder these accesses).  With write caching
:enabled on the disk, the two disks I tested delayed writing one block
:for as long as I tested (several seconds).  I wrote this test in order
:to check some assumptions necessary for a log-structured file system I
:was involved with.  I was not pleased with the result.
:
:- anton

    This will depend heavily on whether you are running SCSI disks or
    IDE disks.

    SCSI disks have an explicit bit that can be set to enable write
    acknowledgement prior to completion of the write.  I don't know about
    Linux, but FreeBSD turns that bit off.  The bit is usually off by default.

    SCSI disks also have an explicit ordering tag.  However, the ordering
    tag has been depreciated in the latest SCSI working standard.  Many SCSI
    disks ignore this tag anyway (which is probably why it is being
    depreciated). 

    IDE disks have historically shipped with this bit turned on... because
    IDE ops are serialized (tagged IDE ops are possible, but not really
    reliable).  In other words, IDE disks tend to lie about write completion.
    We found this out years ago when Kirk McKusick ran a bunch of filesystem
    tests with IDE and was tring to figure out why IDE drives seemed to beat
    out SCSI drives for certain tests.  The manufacturers are more interested
    in getting good benchmark results from the rotten IDE protocol then in
    filesystem recovery.  I'm not sure whether it is possible to turn the
    bit off for an IDE drive but since IDE is essentially a munged SCSI
    protocol over a substandard physical layer, it should be possible.

    This is one reason why nobody in their right mind uses IDE drives on
    critical production systems, not unless the drives are in a RAID cabinet
    with backup power and non-volatile ram.

						-Matt

 

 

 
Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds