On Tue, 06 Jun 2000, Hans Reiser wrote:
> Just because journaling in reiserfs is working and debugged and
> in code freeze for 2.4 doesn't mean that we are more than halfway
> down the path of what we are going to do in journaling. We will
> be doing wandering logs, and journaling in ReiserFS has another
> 18 months of DEEP innovations planned for it. Standardization
> bureaucrats should stay out of the way, we need to code.
Sysadmin cutting in. I'm not responding to give either praise nor
criticism to Hans. I'm just marking off my view as a sysadmin who
doesn't do any kernel-level development, but has production
Linux fileservers with 100s of GBs of data. fsck takes
1.5hours/100GB on these systems after an improper shutdown
(not once due to any Linux crash, but usually due to a stupid
sysadmin mistake in run-time tinkering -- which usually only happens
about every 3 months or so ;-).
Anyhoo, If Linux has thought us anything (at least what I can see
from the sysadmin standpiont), working features are key.
Competition is healthy and any common models or standardization of
components or interfaces can be worked out after the fact. This is
largely because we have source and we can integrate what we do and
don't want. Changes can come later, and I think everyone in the
Linux development community, at least the kernel, has shown great
respect for
I'm building a new fileserver in July. It will house over half a
terabyte of data, which will, in all likelihood, be augmented to
over a Terabyte within a year. This fileserver will be responsible
for housing the files for a 32-bit SoC (system-on-a-chip) design,
with Solaris, Linux and NT clients. We throw data around like it
is a rag doll, checking in files as large as 1GB into CVS.
I am looking for a 64-bit filesystem with metadata journaling (or
at least something like softupdates on *BSD's FFS), and NFS v3
services. The sooner these features are available, and stable, the
better. I understand that things don't happen overnight, but when
someone has got working code that doesn't bloat the OS nor Linus'
respected KISS principle (i.e. doesn't introduce things that
shouldn't be in a basic kernel) , it should be included in the
experimental kernel at the earliest convience -- propogating to the
Darwinism seems to work perfectly in the Linux/OSS world. And in
many cases, more than one survives -- even in user space (e.g.,
Qt/KDE and GTK+/Gnome, Emacs and Vi, etc...).
Just $0.02 from a sysadmin perspective (which means I could be
leaving a number of unforseen things out ;-).
-- TheBS
P.S. If anyone has any suggestions regarding a new Linux server
being built in the July timeframe (opinions on kernel, hardware or
possibly running FreeBSD with its softupdated FFS and NFS v3
server instead?), feel free to do so by mailing me directly. I'm
probably going to push it by using an pre-release 2.4.x kernel if
2.4.0 isn't out by July -- and ReiserFS is probably going to get
the bill.
--
Bryan "TheBS" Smith -- Engineer, IT Professional and Hacker
E-mail: mailto:thebs@theseus.com,b.j.smith@ieee.org
Disclaimer: http://www.SmithConcepts.com/legal.html
*************************************************************
TheBS ... Serving E-mail filters to /dev/null since 1989
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:23 EST