See also: last week's Letters page.

Letters to the editor

Date: Mon, 22 Jan 2001 14:16:20 -0700
From: Andrew Gilmore <andrewgilmore@my-deja.com>
To: lwn@lwn.net
Subject: Dell Linux Laptops

Your main page from last week mentions Dell's laptop page.
(http://www.dell.com/us/en/bsd/topics/segtopic_linux_001_linux_center.htm). 

This page is indeed about Dell Linux laptops, but all of the links to anywhere
on that page fail. I know that the Inspiron 7500 mentioned on that page is no
longer being built, I'm not sure about the Latitude CPx.

I'm not sure what to make of the linux laptop thing either. :(

Andrew

-- 
Hydraulic Engineer, Upper Colorado Region
US Bureau of Reclamation
125 S State St, Room 6107, UC-433
Salt Lake City, UT 84138-1147  PH: 801-524-3879 Fax: 801-524-3858

Date: Fri, 19 Jan 2001 07:42:39 +0800
From: Nick Urbanik <nicku@vtc.edu.hk>
To: letters@lwn.net
Subject: Pronunciation of Linux

I call Linux so it rhymes with "Linus" in the Peanuts comic strip, and
enjoy defending my right to say it that way.  Do I need to put on an
Seattle accent when I refer to Bill Gates?

Date: Thu, 18 Jan 2001 12:06:33 -0800
From: Gene Mosher <gene@viewtouch.com>
To: lwn@lwn.net
Subject: VA Linux

Hey, VA Linux is prohibited by Intel, which owns ten percent of it, from
selling AMD systems.  So, while everybody else is doing well, VA Linux
just keeps bleeding to death.  How can it fulfill its obligation to its
shareholders by refusing to sell AMD systems?  Obviously it can't.  If
you look at the Nasdaq, you'll see that Techs are having a VERY good
month, but not VA Linux, Red Hat, Caldera or Neoware.  The light at the
end of this tunnel is a train coming right at them.  Even the employees
are dumping all their shares while they still have any value at all.  $7
a share may be a lot higher than what the share price will be later this
year.  Just because the share price is two to three cents of what it was
a year ago doesn't mean that it can't go a LOT lower.  It could well
fall to nine cents per share.  Look at what happened to NCDI, for
instance.  Last summer people were bragging about how they were able to
scoop up NCD shares for $9.  Well, three weeks ago it fell to nine
cents.  Public companies which are losing money are not long for this
world.  Public companies which never have made money since their
inception as private companies OUGHT to be sued by shareholders.  It's
the only recourse which stockholders have against a company whose
officers took their money, which can't deliver shareholder value and who
think that they can ignore their lawful obligations to do their best to
do so.  VA Linux and Red Hat have followed pied pipers like Eric Raymond
right off the edge of the cliff, singlehandedly making it virtually
impossible for any Linux organization to get the benefit of public
financing, even if, unlike VA Linux and Red Hat, they have a VALID
business model.  Shame on them.  C'mon, give us some good journalism
about this, whydoncha?

Gene Mosher

Date: Thu, 18 Jan 2001 15:45:47 -0500
From: Derek Glidden <dglidden@illusionary.com>
To: letters@lwn.net
Subject: Linux, NFS and journaling filesystems


[I apologize in advance for the length of this letter, but I think some
of my recent, and past, experience might be of significant interest to
other Linux users out there.]

In your Jan 18th newsletter in the discussion on ReiserFS (huzzah for
ReiserFS making it into the 2.4.1 patch!) you say, "bear in mind that
NFS still can not serve files from a ReiserFS partition" and there is
extensive discussion on ReiserFS/NFS compatibility on the ReiserFS FAQ
section of the ReiserFS site at www.namesys.com.

However, despite all these reports to the contrary, I've successfully
run an NFS server with a 52GB exported volume utilizing ReiserFS on my
home network for several months now with no problems.  Initially the box
was RedHat 6.x based with 2.2.16 kernel and ReiserFS patches, and has
variously incarnated through several kernel revisions and a major distro
change to its most recent state of Debian 2.2 with kernel 2.4 and
ReiserFS patches.  

The main volume has been a 52GB "md"-driven RAID0 volume comprised of
two 26GB IDE drives, formatted ReiserFS, and it has served its files up
with knfsd straight off of whatever kernel/distro it happened to be
running at the time with only ReiserFS, mingo's RAID and hedrick's IDE
patches applied.  I've never had any problems with the three or four
client machines that may be accessing the box at any given time.  (Yeah,
I really have a home network with a huge fileserver and three or four
client machines that might be using it at any given time.  So I'm a big
geek.  :)

ReiserFS has served me well in both testing environments and
"real-world" situations; I can't think of any occasions where I've
experienced any sort of problems with the ReiserFS volume and never any
data loss.  Remount times after any sort of failure (even having a UPS
on the machine won't prevent someone from accidentally bumping the
"reset" switch while it's doing something...) have been great (i.e.
virtually nonexistent) compared to the hour-long fsck times I used to
have even with smaller ext2 filesystems.

With the recent release of the 2.4 kernel, however, I've started playing
with alternate configurations.  I've just this past week "retired" the
old fileserver and, with a couple of new hard drives, have rebuilt the
new primary fileserver using two 61GB IDE drives, integrated into a
single 120GB volume with LVM (http://www.sistina.com) formatted using
SGI's XFS filesystem (http://oss.sgi.com/projects/xfs/) and running the
2.4.0 kernel on Debian 2.2.

Instructions for those attempting this at home: check out SGI's CVS
version of the 2.4 kernel with the XFS mods already applied. Check out
the most recent CVS of LVM from Sistina - the LVM patch that (kind of
accidentally) went into 2.4 was not ready for real use and has a couple
of real showstopper bugs. Follow the LVM instructions for patching
against the 2.4 kernel using the checked out kernel source from SGI.
Configure, compile and install.  The toolchains for LVM and XFS should
both be in your CVS checkout trees ready for compiling and using.  If
you're running Debian 2.2 and want to run Kernel 2.4, you'll have to get
the latest modutils source from the unstable tree and build and install
it.

XFS is surprisingly well along its road to "release-quality" for a
project that the vast majority of the public thinks of as "still under
serious development."  Mount and check times with XFS are significantly
faster than  ReiserFS (which is really saying something if you've ever
been amazed at the zero-fsck mount times of ReiserFS) and I have
definitely noticed an improvement in NFS speed, although I can't
directly attribute this to either improvements in NFS code in the 2.4
kernel or moving away from ReiserFS as the base filesystem for the NFS
volume.  (Although I'd probably point a finger at ReiserFS for the
slowdown as I did run the machine with 2.4/ReiserFS for a few days and
didn't notice any significant difference in its behaviour during that
time.)

Over several days of "hardcore" testing, I've concluded that, for me
personally, XFS is stable enough to form the base for my newly-built
fileserver.  It has been very reliable in my
completely-and-utterly-scientific "rsync a big chunk of data onto the
volume while doing an rm -rf against a copy of the mozilla source tree
and running a perl script that writes, copies and deletes a bunch of
temp files and then pull the plug" tests, mounting nearly instantly on
restart and with the "xfs_check" tool reporting no problems with the
filesystem afterwards.

But why would I move away from a proven architecture to do something
crazy like this?  

LVM gives me the ability to add new physical volumes to the logical
volume on my fileserver without having to rebuild the volume, which is
something I've sorely missed as that machine has been upgraded several
times from its original 8GB filesystem and each time I've had to build a
"backup" server to migrate the data to temporarily while I rebuild the
new server.  Both XFS and ReiserFS include tools for growing an existing
filesystem to account for newly-available volume space and there are
tools available for doing this to an ext2 filesystem as well so any of
those filesystems will work with LVM without much hassle.  I had no
problems at all growing any of those three filesystems, with or without
data already on them, to account for newly-added space on an LVM volume
during my tests.

The choice to go with XFS over ReiserFS was partially based on the "geek
factor" of using XFS but also partially the fact that a larger set of
useful userspace tools comes with XFS than with ReiserFS, not the least
useful of which are the "xfsdump" and "xfsrestore" tools.  (And let's
not overlook the fact that XFS uses full 64-bit file offsets while
ReiserFS "only" supports 60-bit file offsets... :)  However, ReiserFS
has been very very reliable for me and we have been deploying ReiserFS
on machines at work for several months now without a single glitch.  

Other users interested in ReiserFS or XFS are encouraged to visit the
respective websites and do as much research as they feel necessary.  I
feel that at this point in their development, either one would make an
ideal base for a system that needs an extremely reliable filesystem with
little-to-no downtime.  With the important caveat:

*** Both ReiserFS and XFS (and any journaling filesystem on Linux at the
moment) will have problems dealing with software RAID5 volumes, but at
least as of now, behave properly with mirroring, striping and
concatenating RAID methods with either md or LVM drivers.  This is
likely to change in the future, and hardware RAID will not have any
impact on either of them as hardware RAID will look like a single device
to the Linux VFS layer, which is where the incompatibilities hide.

The Namesys website, as you mentioned, has an incredible amount of
information about ReiserFS, going well beyond its journaling
capabilities.  There is also an excellent article on ReiserFS by one of
its primary programmers in the most recent Linux Journal magazine that
not only points out some of the highlights of ReiserFS but also, very
honestly, some of its shortcomings.

The future of the 2,4 kernel series is looking bright indeed with
projects like ReiserFS, XFS and LVM coming over the horizon.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
With Microsoft products, failure is not           Derek Glidden
an option - it's a standard component.      http://3dlinux.org/
Choose your life.  Choose your            http://www.tbcpc.org/
future.  Choose Linux.              http://www.illusionary.com/