ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   01 Mar 2001  18:11:10
 To : All
 Subject : URL: http://lwn.net/2001/0301/kernel.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] 
    
                                [2]Click Here 
    [LWN.net]
    
    Sections:
     [3]Main page
     [4]Security
     Kernel
     [5]Distributions
     [6]On the Desktop
     [7]Development
     [8]Commerce
     [9]Linux in the news
     [10]Announcements
     [11]Linux History
     [12]Letters
    [13]All in one big page
    
    See also: [14]last week's Kernel page.
    
 Kernel development
 
    The current stable kernel release is still 2.4.2. Linus has issued no
    2.4.3 prepatches as yet. Alan Cox has not slowed down, however; his
    prepatch series is up to [15]2.4.2ac6. As usual, it contains a great
    many fixes, including another important ReiserFS "zero byte" fix.
    
    A question went out on the differences between Linus's releases and
    the "ac" patches. There is no definitive list of patches that are
    unique to one or the other (Alan has no time to maintain one). The
    "ac" series does tend to pick up everything that goes into the
    official Linus release, but the reverse is certainly not true.
    
    Linus [16]characterized the difference between the two releases
    thusly:
    
      The two series are fairly disparate, as they have different
      intentions. Alan accepts some stuff that I would be nervous about,
      and sometimes I say "to hell with it, we need to fix this" and make
      Alan nervous.
      
    Alan, instead, [17]described it this way:
    
      I think the key word is actually probably 'predictability'. The
      Linus tree is conservative. (IMHO too conservative and probably in
      his not conservative enough 8))
      
    It looks like we'll have two stable development series for a while.
    
    Meanwhile, the 2.2.19 prepatch is up to [18]2.2.19pre16. In [19]a
    separate posting, Alan stated that the real 2.2.19 release is about
    one week away.
    
    A patch to make NFS work well with ReiserFS was [20]posted by Neil
    Brown. As was discussed in [21]last week's kernel page, the changes
    involved are significant. So, as Neil states:
    
      Alan Cox has suggested that these changes may not be appropriate
      for 2.4, so we might have to wait for 2.5 to see them on
      kernel.org, but we don't have to wait till then to find the bugs.
      
    That announcement brought out a (predictable, perhaps) set of
    complaints about yet another stable kernel series with NFS problems.
    With 2.2, much of the trouble only really got cleared up with 2.2.18,
    released late last year. And there are still some interoperability
    problems that will only be fixed when 2.2.19 comes out.
    
    On the 2.4 front, some patience will be required. The Powers That Be
    may well eventually relent and include Neil's patch if the need
    appears to be strong enough. But it certainly will not happen until
    the 2.4 series appears to be rock solid, and experience says that
    could take a little while yet.
    
    Per-process namespaces are now available for Linux, thanks to [22]a
    patch posted by Alexander Viro ("He's back. And this time he's got a
    chainsaw."). The idea is based on the [23]Plan9 concept by the same
    name. Essentially, every process in the system gets its own view of
    the filesystem. Filesystems can be mounted for one process while being
    entirely invisible to others. Namespaces can be thought of as a much
    more flexible form of the chroot() system call.
    
    Alexander has also posted [24]a tiny program which starts a shell
    running in its own namespace, which is useful for testing out the
    idea. And, of course, he is looking for testers who can find the
    problems with the patch. Those waiting for a stable version will do so
    for a while - this patch is intended for the 2.5 series, once it gets
    started.
    
    Directory indexes for ext2 are another topic that was discussed last
    week in this space. The discussion continued, but branched off into a
    couple of interesting areas.
    
    One is in the area of hashing functions. The directory index function
    depends heavily on a good hashing function to spread the entries
    evenly across the index. So several candidates have been evaluated by
    running them in a usermode Linux kernel; the results have been
    [25]summarized by Daniel Phillips.
    
    The executive summary is that Daniel's own hash function won. In the
    process, it handily beat the dentry hash function, used since the 2.1
    days in the dentry cache. Linus was [26]not entirely surprised by this
    result:
    
      It looks like the hash function was done rather early on in the
      dcache lifetime (one of the first things), back when nobody cared
      about whether it was really good or not because there were many
      much more complicated questions like "how the h*ll will this all
      ever work" ;)
      
    So, as a side result, expect to see some work done on the dentry hash
    function in the near future.
    
    Even more soundly beaten was the "R5" hash used in ReiserFS. In this
    case, the problem is not that R5 is a poor hash function; it was,
    instead, written to satisfy a different set of objectives. R5 will put
    similar filenames next to each other, which makes the ReiserFS lookup
    algorithm faster. For the ext2 directory index, however, it is more
    important to spread things out evenly, so a different function is
    called for.
    
    The "hash wars" are not done yet; though. Expect some new contenders
    to show up before too long.
    
    Meanwhile, people started talking about backward compatibility. Ted
    Ts'o [27]pointed out that, with a very small change to the way the
    index is stored on disk, full compatibility can be maintained with
    older ext2 implementations. The cost, in the form of lost space in the
    directory index, is quite small - less than 1%. Daniel Phillips has
    not adopted the compatible mode completely, however - he plans to
    support it as an option in the code so that people can choose the
    implementation they like better.
    
    When the discussion moved on to tail-block fragmentation, however,
    Linus felt the need to jump in and argue against backward
    compatibility. Tail-block recursion is the process of splitting up
    blocks in the filesystem to allow them to hold the last parts of
    multiple files. Imagine you have an ext2 filesystem with a 4096-byte
    block size, and a 5000-byte file to store there. That file will occupy
    two blocks, with only 904 bytes being stored in the second. Thus,
    almost half of the space used is wasted. In filesystems that store a
    lot of small files (netnews partitions being the classic example),
    large amounts of space can be lost. ReiserFS will store small files
    efficiently, but ext2 has never had that capability.
    
    When Mr. Phillips mentioned plans to provide tail-block fragmentation
    for ext2, Linus [28]jumped in and asked that it not be done. He has no
    objection to the technique, it's just that he thinks a whole new
    filesystem should be created. Rather than just graft on tail-block
    fragmentation, a complete rethink should be done to create a better,
    extent-based filesystem with a vary large block size. And it should
    not be called "ext2."
    
    In [29]another posting he explained his reasoning in more detail; it
    is an interesting look at his philosophy for the evolution of the
    Linux code. Essentially, creating a new code base makes it easier to
    eventually get rid of the old one, leading to better long-term
    maintainability. A transition to a completely new filesystem can be
    done on the user's own time, and can happen relatively smoothly.
    
      In comparison, if you have "new features in X, which also handles
      the old cases of X" situation, you not only bind yourself to
      backwards compatibility, but you also cause yourself to be unable
      to ever phase out the old code. Which means that eventually the
      whole system is a piece of crap, full of old garbage that nobody
      needs to use, but that is part of the new stuff that everybody
      _does_ use.
      
    This is why, for example, Stephen Tweedie's journaling filesystem is
    called "ext3."
    
    Will Mosix go into the kernel? [30]Mosix is a fancy clustering system
    which implements a lot of nice features, such as process migration.
    Many folks would like to see Mosix, or other clustering
    implementations, go into the standard kernel sometime in the 2.5
    development series. There is, of course, no way to know if that will
    happen at this point. However, Rik van Riel has [31]created a mailing
    list where representatives of the various clustering projects can
    discuss the idea together.
    
    Other patches and updates released this week include:
    
      * Folkert van Heusden has posted [32]a patch which implements the
        generation of random process ID numbers.
      * A [33]boot log from a 64-bit PowerPC system was posted by Peter
        Bergner of IBM.
      * David Miller has posted [34]beta 3 of the zero-copy networking
        patch
      * Keith Owens has released [35]modutils 2.4.3, "just a small
        collection of bug fixes." Keith has also released [36]version 1.8
        of the "kdb" kernel debugger.
      * IBM has turned loose [37]jfs 0.1.6, the latest release of its
        journaling filesystem.
      * Greg KH has [38]announced a new hotplug scripts release.
      * Douglas Gilbert has [39]posted a driver for a new 'scsiinfo'
        device which implements initial support for hotplugging of SCSI
        hardware.
        
    Section Editor: [40]Jonathan Corbet
    March 1, 2001
    
    For other kernel news, see:
      * [41]Kernelnotes
      * [42]Kernel traffic
      * [43]Kernel Newsflash
      * [44]Kernel Trap
    
    Other resources:
      * [45]Kernel Source Reference
      * [46]L-K mailing list FAQ
      * [47]Linux-MM
      * [48]Linux Scalability Project
    
    
    
                                                   [49]Next: Distributions
    
    [50]Eklektix, Inc. Linux powered! Copyright Л 2001 [51]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://ads.tucows.com/click.ng/pageid=001-012-132-000-000-003-000-000-012
    3. http://lwn.net/2001/0301/
    4. http://lwn.net/2001/0301/security.php3
    5. http://lwn.net/2001/0301/dists.php3
    6. http://lwn.net/2001/0301/desktop.php3
    7. http://lwn.net/2001/0301/devel.php3
    8. http://lwn.net/2001/0301/commerce.php3
    9. http://lwn.net/2001/0301/press.php3
   10. http://lwn.net/2001/0301/announce.php3
   11. http://lwn.net/2001/0301/history.php3
   12. http://lwn.net/2001/0301/letters.php3
   13. http://lwn.net/2001/0301/bigpage.php3
   14. http://lwn.net/2001/0222/kernel.php3
   15. http://lwn.net/2001/0301/a/2.4.2ac6.php3
   16. http://lwn.net/2001/0301/a/lt-releases.php3
   17. http://lwn.net/2001/0301/a/ac-releases.php3
   18. http://lwn.net/2001/0301/a/2.2.19pre16.php3
   19. http://lwn.net/2001/0301/a/ac-oneweek.php3
   20. http://lwn.net/2001/0301/a/knfsd-patch.php3
   21. http://lwn.net/2001/0222/kernel.php3
   22. http://lwn.net/2001/0301/a/namespaces.php3
   23. http://plan9.bell-labs.com/plan9dist/
   24. http://lwn.net/2001/0301/a/rfork.c.php3
   25. http://lwn.net/2001/0301/a/hashes.php3
   26. http://lwn.net/2001/0301/a/lt-dentry-hash.php3
   27. http://lwn.net/2001/0301/a/tt-compatibility.php3
   28. http://lwn.net/2001/0301/a/lt-tail-block.php3
   29. http://lwn.net/2001/0301/a/lt-compatibility.php3
   30. http://www.mosix.cs.huji.ac.il/
   31. http://lwn.net/2001/0301/a/cluster-list.php3
   32. http://lwn.net/2001/0301/a/random-pid.php3
   33. http://lwn.net/2001/0301/a/powerpc64.php3
   34. http://lwn.net/2001/0301/a/zerocopy.php3
   35. http://lwn.net/2001/0301/a/modutils.php3
   36. http://lwn.net/2001/0301/a/kdb.php3
   37. http://lwn.net/2001/0301/a/jfs.php3
   38. http://lwn.net/2001/0301/a/hotplug.php3
   39. http://lwn.net/2001/0301/a/scsiinfo.php3
   40. mailto:lwn@lwn.net
   41. http://www.kernelnotes.org/
   42. http://kt.zork.net/
   43. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
   44. http://www.kerneltrap.com/
   45. http://lksr.org/
   46. http://www.tux.org/lkml/
   47. http://www.linux.eu.org/Linux-MM/
   48. http://www.citi.umich.edu/projects/linux-scalability/
   49. http://lwn.net/2001/0301/dists.php3
   50. http://www.eklektix.com/
   51. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор