Slashdot Mirror
Ask Slashdot: How Reliable are Enormous Filesystems in Linux?
Josh Beck submitted this
interesting question:"Hello. We're currently using
a Mylex PG card and a pile of disks to run a 120 GB RAID5 under
Linux. After some minor firmware issues with the Mylex
(which their tech support acknowledged and fixed right away!)
, we've got a very stable filesystem with a good amount of
storage. My question, though, is how far will Linux and e2fs
go before something breaks? Is anyone currently using e2fs
and Linux to run a 500+ GB filesystem? "
Josh continues...
"I have plenty of faith
in Linux (over half our servers are Linux, most of the rest are
FreeBSD), but am concerned that few people have likely
attempted to use such a large FS under Linux...the fact
that our 120 GB FS takes something like 3 minutes to
mount is a bit curious as well, but hey, how often
do you reboot a Linux box?"
.. this could become some fine 'success story'
if it works ok. Anyway I hope you continue to
run as normal (ie. keeping linux), even if its a major production system because it's great feedback to the developers, and maybe even ironing out a few bugs if you encounter any. (giving back to the community, instead of going with something more tested, because if nobody drives linux to the limit, who will then be able to look at any references when they are to choose systems?)
Have you been thinking about another FS maybe?
There's UFS support and alot other. Ofcourse
the linuxport might not be as stable as they
would in UNIX(tm) or BSD, but you get the point.
Hey, Netware's not Linux, but there's no reason for Netware to crash that often if its done right. You have a different problem, bud, not Netware.
As a previous poster noted, fsck:ing such large filesystems is a pain. In a Solaris-environment SUN recommends journaling when at a 40GB-filesystem. AIX only has journaling filesystems.
This is one of the big reasons not to use large filesystems in Linux.
Just out of curiosity: Could someone "crash" a large filesystem and then time the fsck ? I mean, someone out there must have a couple of 18GB disks to play with :-)
I'm curious are you planning on backing up that partition, or to restore it? RAID doesn't mean you don't need backups and a partition that size is pure MURDER!
If you are planning on, or are currently backing it up, how long does that take, and have you done any research into how long it takes to restore various amounts of data?
He has built ext2fs... card@csi.uvsq.fr
I read somewhere the linux filesystem was good up to two terabytes.
We've got a 200GB RAID for our Origin 2000, and we also have a DLT tape robot .. it's a cabinet with a couple of drives, a transport arm, and a rack of tapes. It makes a full backup every weekend (when the RAID isn't being used much) and partial backups every day. Very convenient, if you can afford it.
Call Sam Ockman at Penguin Computing. He's built some serious boxes for us the likes of which you won't likely see on their web site. They've been much better to work with than VA Research has been for us (then again, we only bought one order from VAR and ever since have been buying hardware from the other guys).
Hi,
Why not look into AFS, transarc makes a commerical
AFS server for linux. I have not used it on linux yet, just on AIX machines. We have 4+T on AIX machines where I'm at, but I"m sure some linux AFS server would have no problem at such large sizes.
I'd personally go ahead, decode the mysteries of the XFS filesystem(SGI's). And use It! It's rock stable, fully journaled, and even tells you when shit happens(yeh:-) and fixes it! well....maybe ext2 does too....but....
Hey,
anybody got some experience with Dat Tape Changers ( HP ??48al ) on Linux ?
uwe.klein@cruise.de
There are a bunch of universities in the US that share the Andrew File System. It's an FS that was made at Carnegie Mellon and is maintained by the universities that use it. I'm sure that you can mount AFS drives on a linux box, but using them as servers I'm not sure about. I'm pretty sure the universities use Solaris for the servers.
You can also use tune2fs if you've already created the filesystem - of course, you need it unmounted to change it (can't remember whether it'll work if it's just mounted read-only).
On the contrary, reducing the reserve spaced would be a very *BAD* thing to do. Yes, part of the reason for the reserved space is so that root can always have some space to play with, but the much more important reason is so that the file system doesn't get fragmented.
Reserving 5% of the disk means that there will almost always be a "free block" near by. This percentage doesn't change as the disk size changes. For the 5% value, you will typically not need to go futher than 20 blocks to find a free one (5% = 1/20).
For a disk like this, I would think you would actually want to *increase* the reserved space to keep the amount of seeks down. The BSD Fast File System papers showed that you needed at least 10% to keep the system fast. I really don't think any similar studies have been done for ext2fs, but I would suspect that it was similar.
It seems Linux with a supported RAID card and SCSI disks can support 500+GB filesystems reliably and even efficiently if you have the journaling patches. But how about the reliability of more mundane medium-sized IDE filesystems, eg in the 5-20GB range? I guess most people here are using IDE disks rather than SCSI disks.
Would anyone else care to run the IDE disk test below and share their results here giving your IDE/motherboard specs? On my machine this test intermittently generates file read errors on reading large files from IDE disks
1. Create a large 10MB test file on an IDE partition.
2. Do lots of checksums using sum or md5sum.
- sum bigfile
Q: Do you get the same checksum each time?sum bigfile
sum bigfile
repeat 20-30 times
I get different answers intermittently. If I do a byte-wise difference between two identical files it reveals bytes are occasionally misread with bit 5 being flipped randomly i.e. the values are +/- 32 from the correct value.
My setup is a Supermicro P6SLA motherboard with Intel 82371AB PIIX4 IDE interface and Quantum Fireball 6-16GB IDE disks with 12-13 MB/second transfer rates. DMA but not UDMA is on, but this makes no difference apart from speed to my results. If the hardware had a fault, I should see the errors under Win95 but I don't.
The IDE driver for all current kernels 2.0.x and 2.2pre/2.1.x kernels has a bug relating to DMA status signalling (see Mark Lord's reply in kernel mail list 15 Dec 1998).
Hi,
I don't run any monster filesystems i e 100 Gb +, the biggest filesystem we have got at our site is some 70 Gb, although we have a couple of volumes in that size.
However we had the need for a big and *really* cheap fileserver. And being a linux fan I took an old P166 that was lying around, bought 4 quantum fireball 12 Gb and installed linux and created a single filesystem spanning over the disks using raidtools raid0. Everything counted of the usable disk that was left was some 43 Gbs.
I know that raidtools is currently beta software. But it works quite well. It is easy to setup and quite fast.
The server stability is ok, it crashes now and then, maybe once a month. Don't know if it a hardware or a software problem. I havent had the time to look into it.
The ext2 filesystem seems to be the more stable part of the raidtools/ext2 combination we use.
The server is backed up using our legato networker backup server, which works very well.
My previos experience in large filesystems are all on sun-servers using much more expensive hardware and management tools disksuite/veritas. Those servers are rock-solid, fast and expensive.
To sumarize, the server gets the job done at a unbeatable prize/performance ratio, it could be better.
I am looking forward to see what comes out of the logical volume project.
Hi,
This is more important, IMO. When does Linux get LVM?
LVM + JFS = Satori..
Doesn't IBM have an ADSM client for Linux? A company called EMASS makes an IBM 3494 compatible tape library that will hold around ~6.9 terrabytes for about the half the price and half the footprint of a genuine IBM 3494 tape library. Thats more storage then your likely to need, but you can start adding extensions if you need more. Of course, you still need a non-Linux machine to run the ADSM server software, but look for that to change.
Macs have had a b-tree based file system for quite a while. I've always thought it wasn't well suited for multi-user systems because you have to lock most of the filesystem when maintaining the b-tree.
This is *nix, you can split up partitions and use symlinks to redirect a directory onto a different partition. I see this all the time on many large ftp archives. This has advantages in terms of reliability and ability to check the filesystem on individual partitions without bringing everything offline. You'll definitely want to use subdirectories if you have lots of files, because e2fs doesn't handle directories with large numbers of files very well (it slows to a crawl).
AFS is a distributed file system. It allows
the seemless combination of multiple servers
into one filesystem. A big RAID on an
AFS server would still need to have an ext2 (or
similar) partition(s).
AFS is used a lot for universities because
there is no need to know the machine name
to get to a networked resource. It is all
mapped to directory names in a cell (ie.
athena.mit.edu) by AFS volume servers.
Transarc just announced commercial support for
Linux, but I do not know if that includes the
server portions of AFS, probably just the clients.
You haven't mounted this mother async, have you?
K6-333; MVP3 chipset, IDE 6.4GB, 128MB., RedHat 5.2, 2.2pre7
40 loops, no errors.
lates.
another thing to keep in mind when dealing with netware is it absolutely hates ide drives, scsi is the way to go with netware, and if your going to have large volumes, you ought to check out nss.
you could power off a server in the middle of a major database update and the nss volume would mount up instantly without any problems, now you would probably have some database integrity problems, but atleast the file system is in tact
if you use a real raid controller in a real server such as a compaq proliant w/ a smart array 2 controller, the cache on the raid controller is protected by a battery pack so in the event that the server loses power during writes, it can finish writing its cache when the power comes back on before the file system is ever booted
no, see, what you need is an Ampex DST 812 tape library. 12.8 TB capacity, 80 MB/sec sustained data rate. nice!
Red Hat has Steven Tweedie working on a fully journaled file system for Linux. I haven't heard the release date. Maybe someone who knows Tweedie could ask him. [ sorry if I misspelled S.T.'s name.]
LVM is here.
http://linux.msede.com/lvm/
Alpha software but I've tried it and it actually works!
Actually, the P2 core has a 36-bit address bus. I'm not sure how you're supposed to address this from software, though, since 32-bit is pretty ingrained in the MMU structures.
Excuse me, but I have run into some badly written NLMs full of memory leaks and some really cleanly written NLMs. What determines if a NLM is cleanly written or not seems to have nothing to do with if it is third party. I believe the following NLMs I have had expierence with are still consider "true red" (from Novell). In fact, if you aren't running ANY third party backup software then you probably have yet to have a reliable backup.
Servers running GroupWise 5 based NLMs (and no third party):
POA (Post Office Agent):
Average time til auto-abend recover:
Less than 24 hours
Average time til complette server halt:
Less than 2 weeks
SMTP (GroupWise to Internet gateway):
Average time til complette server halt:
Less than 3 days
Web Access Gateway+Novonyx:
Average time tel complette server halt:
Less than 12 hours
One the other hand, we have had servers running ADSM v3 (beware of ADSM v2) and Open File Manager on servers that have remained up for months.
It would be nice if Novell took a hint from IBM/Lotus and started providing some of their GroupWise server & client services for Linux. Getting those GroupWise (third party?!) NLMs off Novell (and not onto NT) would definately help Novell image, at least at where I work.
That's ridiculous. Any commercial 32 bit UNIX has no such limitation. In this respect Linux is just lame, there's no two ways about it.
I don't buy the efficiency reasoning either. As you point out it wouldn't be POSIX to change the library call types (seek/fseek/tell/ftell et al) so new calls are required (seek64 or whatever). Hence applications using the old entrypoints have no efficiency hit. Besides, we're talking about file access here, even a fairly large amount of CPU overhead will be swamped by the actual time it takes to do the I/O operation.
I'm working on a product that requires large files and as a result Linux is completely ruled out. I'd love to port to Linux, but it's just not possible. So we can go Alpha as you suggest, or we can just screw Linux and use a non-crippled OS.
According to this website, TransArc has both AFS clients and servers for Linux: http://www.transarc.c om/Support/afs/news/linux.for.afs35.html
It works just fine on my Asus TXP4 w/P200, 128MB DIMM, 8.4GB UDMA IBM Deskstar. I actually used a dump from an old (and full) 135MB drive which I had sitting around. It does take almost 25 seconds to complete, though.
It shouldn't take anywhere near 5 minutes to mount 9Gb volume. That's a fairly small volume when working with Netware.
I'm using a 17.2 Gb volume and the mounts take less 5 seconds if that long. That is assuming that the filesystem isn't damaged and that you don't have to run vrepair (the fsck equivalent) which on my volume requires less than 2 minutes.
With mount times like that you've got one of several problems: 1) lack of memory on server (I'm using 128Mb and that's the minimum I would run with, Novell has a formula to calculate the amount of memory necessary to adequately use a volume), 2) Server hasn't got adequate processing power (doubtful), 3) inadequate I/O subsystem.
Although the Mac's use of b-trees in its filesystem might not be the best, b-trees in general are very good for multiuser situations. They have a high degree of locality when updating on-disk structures. Certainly a b-tree structure requires at most the same degree of locking as simpler structures and, usually, considerably less.
SCO Open Server 5 has a limitation of 2 Gig...
Where is the best place to get indepth info
on e2fs and how it works. Implimentation,
max size, etc... I have not been able to
find any HOWTO's or FAQ's on the subject
Maxtor EIDE 8Gb drive, P166, Intel Triton MB - works like a charm, no problems whatsoever.
Perhaps the original poster should run an fsck on his/her drive.
- Steve (steve@badcheese.com)
Actually, ReiserFS is faster than ext2, for files not near the node size. It also handles very small 100 byte files exponentially better. And it wastes less space, (its not a block-based filesystem)
And it can be gotten (alpha) for 2.1
http://www.idiom.com/~beverly/reiserfs.html
Linux supplies source. If you want to have files over 4 gigs and you want to use linux, alter the kernel to suit.
Don't blame linux for your laziness and freeloading.
Thanks for suggesting trying hdparm and the other ideas such as reducing IDE cable lengths.
I did give hdparm a try, enabling and disabling various options such as:
- DMA
Despite this the IDE problem has continued.Unmasked IRQs
Readahead count
Internal disk cache
PIO mode
-X transfer mode
One idea I haven't yet tried is to remove a video processing PCI card from the affected PC. The video card (a DVMaster Firewire/Analog Video Capture Card from Fast Electronics) doesn't have a Linux driver (does anyone know of one?) so it doesn't get initialised by Linux and might be in a funny state interfering with PCI bus operations. Soft-booting from Win95 via Loadlin might get around this difficulty.
Read the bloody paper...
Macs use a type of tree for storing directory information, not for storing everything in the filesystem. ReiserFS stores everything in the tree.
Have you actually read the paper, for files not near the node size, it crushes ext2fs by 50-200%.
Ext2 itself is going to get journalling,
along with ACLs and faster directories.
Reiserfs is a new filesystem in alpha test now.
It is usually faster than ext2, and sometimes
it beats the crap out of ext2. The cost is
something like 15000 to 20000 lines of code,
compared to the 6000 currently used by ext2.
XFS is the best damned FS I have ever seen. I have something over 4 TB of disk in a mirrored and striped fibre channel system as JBOD if you can imagine that. The problem is that XFS does not yet run on the Linux platforms. Maybe we should get SGI to release specs/implementations.
:). It is awesome to
/newpath
But I am curious about using SANs, Storage Area Networks, where all the client mounting stuff is taken care of in such a way that they (the client) never really see the disk, just a big old server IP address where it is located. I do not think e2fs can handle a SAN config at this time. Is there any SAN work underway for Linux or do I need to go through an NFS proxy?
BTW: my mount times for my big disks (4TB) are on the order of seconds...., and are configed such that I get about 500 MB/s of sustained IO to and from them (really wide stripes
cp BigAssFile
for files several GB in size, and have it finish in a few seconds.
Mark my words... why on earth would anyone need more than that? Once we move to ext3, we'll never have to upgrade again. Bliss.
NTFS is absolutely not journaled. That's one of the new features that supposed to be in (and supposed to work) in W2K.
Of course, the coopted Veritas to get it, but that's another issue.
http://www.complang.tuwien.ac.at/czezatke/lfs.html is the ONLY semi-working LJFS (logging/journalling file system) I have ever heard for Linux. Unfortunately it is ALPHA/BETA quality and needs testers/porters, ASAP!
A JFS, LFS, or LJFS is ABSOLUTELY NEEDED to end this "fsck time" problem on large file systems. Yes, it can take hours or DAYS to fsck a system!!!
I've seen 36 hours, myself!
Do we have a working JFS system at all, anywhere? I'd be happy to see one, even if it did cost.
Please consider the OpenSource LJFS system, above, though. Help is needed. Something like this SHOULD replace, but be compatible in features to, ext2...
What if you get a disk error?
I have seen IDE drives in particular, but more commonly floppy drives, that get errors but don't correctly report them. That is, I see kernel errors but the process doesn't always realize the action failed!
Although most IDE disks don't use much power when operating, I think it could be that your power supply is getting weak. Check to see if the voltages are in spec when the drives are seeking. You might also want to hook up a scope and check out the amount of noise. Just last week I fixed a win95 PC that would die halfway thru a scandisk on an 8G drive. The bridge rectifier in the PS had a HOLE in it! I was stunned that it worked at all (voltages were about 15% low!). I recommend PC power and cooling supplies, even though they're not much better than the generic brands. Are there any mil-spec supplies available for PCs?
1 Exabyte = 1,000 ?B
1 ???????? = 1,000 PB
1 Petabyte = 1,000 TB
1 Terabyte = 1,000 GB
1 Gigabyte = 1,000 MB
1 Megabyte = 1,000 KB
1 Kilobyte = 1,000 bytes
Okay, so what's between Petabyte and Exabyte? I honestly have no idea.. =)
EraseMe
It can improve performance because the actual writes go to a small area on the harddisk (on Solaris the max. size of the log area is about 64_Mega_bytes). That means several small writes are written to this area and are committed somewhere in the future when the OS / harddisk has nothing to do.
You do NOT have to pay a heavy price for a journaled filesystem. A nice example of this is the particularly modern filesystem used on BeOS. You get metadata journaling (a 3G filesystem mounts in a few seconds after a total crash, like a poweroff during heavy disk activity), extended attributes (possibility to attach arbitrary meta-information to standard files, for example the MIME type of a file - think of them as headers a normal fopen() wouldn't see, for example), and indexing of the attributes (a filename search of the entire filesystem, for example, takes only a couple of seconds). Yet the streaming speed is within a couple of percent of the hardware limit of the drive. Sure, you loose a tiny bit of performance in file creation and append-writes, but not noticeably.
Enormous performance hits come from full data journaling, which essentially requires a RAID system with a separate drive or two for journals only, and everything has to be written twice. If you absolutely need to guarantee no data loss, then you must be willing to pay the price.
Anything bigger than 30Gb, go for a hardware raid box, something like a CLARiiON array (www.clariion.com). They have redundant cache, power, SCSI controller, SCSI busses, Disks, and on board battery backup for the write cache.
To run a reliable and safe system, this is the kind of hardware you need. Expensive though.
Followed by
1 YottoByte = 1024ZB
1 ZettaByte = 1024EB = 2^80 Bytes
for those who like their filesystems big
/usr/src/linux/Documentation/filesystems/vfs.txt
/usr/src/linux/fs/etx2/*
[ Yah, yah, yah...I'm a smart ass. I've never read the code either. ]
Joe
Not true! Please look at amanda, available from University of MD.
We've had to chkdsk 64GB RAIDS... it takes hours, but not days (you musta hadda really fsckd system!)
:).
NTFS is transacted but not journalled. It's less unreliable than FAT but it's still unstable depending on your NT Service Pack (of course, they're all stable until the next fix is available
Agreed, Chkdsk is bad, but is there another tool to repair NTFS?
I would be interested in knowing the database software in use for the huge database at this account.
hmm, wouldn't it be possible to get a largish performance increase on writes by combining journalling and reiserfs? i.e. write directly to disk and garbage collect in the background?
What journalled file systems on UNIX have you been using?
When doing device driver development work for a RAID vendor some time ago under Irix 5.3 running EFS file systems, hourly kernel panics inevitably resulted in trashed file systems about 50% of the time. A short time later, we migrated up to Irix 6.2 and XFS and never ONCE did I lose data.
Even better, XFS could deliver well in excess of the 100 MB/s throughput that the RAIDs provided when doing buffered I/O on large files with large block sizes and just under that when doing direct, non-buffered I/O.
Check out the Laboratory for Computational Science and Engineering. These folks have done some VERY large file systems with XFS and have extracted some very good performance from it. If memory serves me correctly, I think at one point they built a 1 TB XFS file system.
Check out http://viks.mvrop.org/unit/index.html for a complete list
Run a virus scanner that gives you file information on files as it scans and watch carefully as it scans the system32 directory, you will see 16 bit DLL on a couple of files.
Mine has been so positive that I absolutely hate having all these systems around which don't have a JFS.
I used to sleep easily at night when I worked at a place with all JFS. Now during power outages I'm scared to death that when I come in to work the next day my systems are going to be corrupted.
FSCK is ancient crap that should be done away with ASAP.
I've got an XFS with broken files in it that it can't fix. Not supposted to happen eh, well it can.
On the other hand I never had any trouble with AIX JFS.
If you read the Multi Disk HOWTO you will find
- actual reliability figures
- details on how to improve reliability
- info on maintaining large arrays
- and of course how best to use multiple disks
The topic is too big to summarize here, please go to www.nyx.net/~sgjoen/disk.html
and (for the quicker numbers) http://www.nyx.net/~sgjoen/disk-16.html#ss16.6
ALL FEEDBACK IS WELCOME!!! Please guys, I want feedback, I wrote this stuff.
Regards,
Stein Gjoen
Author of Multi Disk HOWTO
It looks the IDE fileread problem was caused by a faulty cache in my 333MHz PentiumII. When I disabled Internal Cache in the (Ami)BIOS from its default setting WriteBack, the problem completely disappeared. The system is too slow to be usable with the cache disabled so I'll claim a replacement Intel PII from the vendor under their warranty.
Thank you everyone for your replies and suggestions about possible hardware faults. Whereas I initially suspected it was due to something fishy about Tux :-), your ideas encouraged me to take a more critical look at the hardware and in particular to try a really thorough test of BIOS options which is how I found the fault.
When will we (do we) have support for files larger than 4 gigabytes ?
There are a few hacks that allow support for files over 4G. You won't see files over 4G supported natively until we move to a 64-bit OS (at which time we will then have support for files up to 18 Exabytes - that is, 18,000,000,000,000,000,000 bytes).
The only way journalling can work reasonably well is if you have a battery backed RAM to hold the journal.
At any rate, 3 MB/s seems too slow, by a factor of 3 or so.
- A.P.
--
"One World, One Web, One Program" - Microsoft Promotional Ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
- A.P. (Yes, I've had several bad experiences with Exabytes.)
--
"One World, One Web, One Program" - Microsoft Promotional Ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
There are a number of well-known websites which utilize Linux, including Deja News. Not sure what kind of partition sizes they're using, but it would be fun to know.
FWIW, you can modify the reserved % parameter using tune2fs rather than mke2fs and save scads of time. You can also force an fsck (man fsck) to time the operation if you want.
What part of "gestalt" don't you understand?
Ext2fs would take months to fsck that thing. :)
There is a log-structured filesystem for linux called "dtfs" available at their home page. The author tells me he will be shooting for inclusion in 2.3.0 and that the bulk of it is working just fine.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
since we're in blatant commercialism mode (sigh).
I prefer the ICP-Vortex GDT line of RAID controllers -- there's even a fibre channel model that works fine with Linux. Leonard Z is a great guy, but I like supporting vendors who support Linux -- ICP-Vortex wrote their Linux driver back in 1.3 days, supports it, and even all of their utilities run native under Linux (none of that bull about booting to DOS to configure the RAID array).
Interesting thing about ext2: mounting a 120gb partition takes about 3 minutes if you mount it read/write, but it's almost instant if you mount it read-only. Apparently it has to pre-load all that meta-data only if you intend to write to the filesystem.
e2fsck'ing that beast took over ten minutes (I don't know how much over 'cause I gave up). Formatting it in the first place took about five to eight minutes, so I aborted my e2fsck and reformatted the partition (this is while I was doing system setup and configuration, so there wasn't any data on it).
We can go up to half a terabyte without going to an external cabinet, using a solid heavy-duty steel California PC Products case and CRU LVD hot-swap backplanes rather than that effete gee-whiz stuff that's flimsy and breaks easily. This is in a dual Xeon 450 configuration. LHS also has a quad Xeon setup that has the horsepower to break the terabyte mark (dual PCI busses, etc.), it's pretty much the same thing VA Research sells (after all, there's not many providers of quad Xeon motherboards for system integrators: Intel and AMI). With commonly available 18gb drives this would require an external RAID cabinet or two. 36gb drives should be available shortly, and those will solve some of the space and heat problems (you better have a big server room for a terabyte of storage using 18gb drives!).
Blatant commercialism. Yetch.
-- E
Send mail here if you want to reach me.
if you mount them read-only. This was with a 120gb filesystem. Obviously it's not doing those basic file system checks upon that kind of mount. I guess I'll have to see what option "check=none" does with a big filesystem next time I have one to play with (which should be shortly, with a 180gb one).
-- Eric
Send mail here if you want to reach me.
The important thing is the filesystem itself. The journal, as I understand it, is just a record of changes to be made. Rollbacks are possible for multiple levels of updates.
If the glitch occurs prior to journal recording then there is nothing to fix.
If the power outage or problem occurs after the journal entry has been made but prior to the commencement of writing then the changes can be rolled forward or back - posted or rejected.
If the problem occurs after journaling but while writing is in progress then the changes can be rolled back and then possibly reposted.
If the problem occurs after journaling and after writing but prior to reconciling the journal then the changes can be rolled back or the journal updated to match the filesystem.
Journaling is good for systems that require very very high reliability - such as banking systems. There is obvious overhead involved in journaling.
An optional, journaling filesystem for Linux would be a nice addition - hey, NTFS for Linux isn't far from being read/write is it?
Codifex Maximus ~ In search of... a shorter sig.
Posted by GregK:
We are selling 1.1TB(that's terabyte)machines currently using the Dac960 and external drive enclosures. You can check out our systems at the following URL;
http://www.varesearch.com/products/vs4100.html
They are quite reliable, mostly due to the fact that the author of the Dac960 Linux drivers,(Leonard Zubkoff), works for us.
Posted by GregK:
Yes.
Posted by Jim @ ImageStream Internet Solutions:
The company I work for has been selling Linux based servers running the linux software raid. It works great in the 2.1 kernel, the largest raid we built under software was 150 gig. We did this to backup a clients old raid system. One of are clients has a server which is running 100 gig raid(linux software) and is moving huge databases on it daily without fail and been up over 6 monthes running 24/7 crunching data.
It seem that for Linux ext2 partition it was discussed that there is some loss for big filesystem (a % of space is lost for superblock copy and such)
you want to turn on "sparse-superblocks" support when doing a mke2fs. it reduces the number of duplicate superblocks. the catch is that it is really only supported in the late 2.1.x/2.2.x kernels. 2.0.x will bawk like a dying chicken.
Sorry, but I don't buy that. Solaris and AIX have no problem with big files on 32-bit platforms. 32-bit platforms are normally limited to 32-bit address spaces (modulo games such as segments and some of the other truly horrible DOS and Windows hacks), but there's no compelling reason why file size and physical memory should be constrained by processor word length.
Wrong answer! I guess your instructor is being paid too much.
l i.htm
See IBM's web page, which shows how to download an unsupported ADSM client for Linux:
http://www.storage.ibm.com/software/adsm/adserc
Reducing the amount of reserved space may save you some space, but it can cost you a *lot* of time. Having 5% reserved space will mean that there will almost always be a "free block" within about 20 blocks from the end of the file.
Unless you want your expensive raid system to spend lots of time seeking, you should keep the 5% min free value, or even increase it to 10% like the BSD folks use. You certainly don't want to constantly run the filesystem close to being full most of the time.
SPF support for most open source mail servers can be found at libspf2.
2. Do lots of checksums using sum or md5sum.
Q: Do you get the same checksum each time?
I once had a problem like this where I would get a corrupt byte from the disk about once very 50-100MB of data read. It happened on two different disks, I tried three different IDE controllers, I swapped RAM, I ran RAM tests, I made sure my bus speeds were within spec. One byte every 50-100MB might not be very high, but it was enough to crash my system once or twice a week.
It turned out that I needed to set my RAM speed in the BIOS to the slowest setting, and everything worked. The RAM test programs didn't detect anything, I think because the errors only occured if I was doing heavy disk access at the same time I was doing very CPU intensive things.
Moral of the story: PC hardware is crap and Unix tends to push the hardware much futher than other systems.
Set your BIOS settings down to the very slowest settings and see if the problem goes away. Try swapping components, and try a *good* memory tester (Linux has one called mem86 or something).
Good luck
SPF support for most open source mail servers can be found at libspf2.
From what I understand, ext3 would be better suited to giant partitions.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Dude, it sounds like you have either some bad memory or are pushing your processor a wee bit too hard. Are you using parity memory? Odds are not, which is fine, but you can get strange results like this. Maybe you should borrow some SIMMs from a friend and see if the problem persists.
It seem that for Linux ext2 partition it was discussed that there is some loss for big filesystem (a % of space is lost for superblock copy and such), don't forget to reduce % of filesystem reserved for root (5% by default, that would be overkill for 120Gb)...
If you find 3mins long to mount a 120Gb filesystem, you should have seen a Netware server with 13Gb, that take at least 5-15 mins to mount the filesystem...
The main problem with Netware (before 5), is the lack of memory protection and a illegal read or write does crash the server (there is an option to ignore this, only use it when developping NLMs)
A well configured Netware server with updates is very stable. For 3rd party NLM, if they are well written, it shouldn't crash the server (I'm also a NLM developper, and Unix programmer. One of my NLM hadn't crashed and the server uptime is about 2 months, and it's used fairly often, it mainly convert print job from Epson FX-80 format to another printer format. NLM are a pain to develop, develop (and test) most of the NLM under another OS, like Linux then to the last few lines under Netware is the best way, with of course set of routines for easy porting between Unix, Netware and Win32 with the same code.)
There is work in progress to develop a binary tree-based filesystem for Linux, which is currently on second beta. The paper and source files are located at http://idiom.com/~beverly/reiserfs.html . It is supposedly faster than ext2, and might be better suited for gigantic partitions, although I cannot attest to that, as I have no experience with it. Does anyone here know anything about this?
In Soviet Russia, Jesus asks: "What Would You Do?"
Tried it, and got the same every time. Setup here is an AST Premmia GX P/100 in single-processor mode (has a 82430LX/NX Mercury/Neptune chipset and PCI and EISA buses), 32MB no-parity RAM, kernel 2.0.35, Western Digital WDAC1600 disk, and a *shudder* CMD 646 rev 1 controller. Well, actually, the disk mentioned above is connected to the second channel, which uses a different controller that gives me problems when I configure it to do IRQ unmasking and 32-bit transfers (the CMD646 does that fine here). I recommend you to try tuning your disk setup with hdparm and try again.
In Soviet Russia, Jesus asks: "What Would You Do?"
Doing writes in this way makes writes go MUCH faster. I read a review by one journalist (no pun intended) who didn't believe Sun's claims that it made long sequential writes go 3x faster or more... It did. Unfortunately, Sun haven't (yet) put full journaled FS support into standard Solaris, though there is an option to put "UFS logging" on - it can also be done on the fly. Still, deleting files and creating lots of small ones goes about 5-10x faster when you put logging on.
A journaling (not "journaled") filesystem is one that keeps track of all the writes it's going to make on a special part of the disk. That way, if you lose power with the disk still spinning, the FS can read its record of "pending transactions" and make the needed changes immediately when you boot again. Journaling thus eliminates the need for fsck'ing. Cool, huh?
The moral of this story: DLTs are a perfectly feasible backup medium. You can get 17GB on one tape.
A journalled file system writes all of the proposed changes to control structures (superblock, directories, inodes) into a journalling area before making those writes to the actual filesystem, then removes them from the journal after they have been committed to disk. Thus if the system goes down, you can get the disk into a sane state by replaying/executing the intention journal instead of checking every structure; thus an fsck can take seconds instead of minutes (or hours).
For example, if you're going to unlink the last link to a file (aka delete the file), that involves an update to the directory, inode, and free list. If you're on a non-journalled system and update the directory only, you have a file with no link (see /lost+found); if you update the directory and inode only, you have blocks missing from your free list. Both of these require scanning the whole disk in order to fix; but a journalled system would just update the directory, inode, and free list from the journal and then it would be sane.
Problems with journalled filesystems include conflicts with caching systems (e.g., DPT controllers, RAID subsystems with cache) where the intention journal is not committed to physical disk before the writes to the filesystem commence.
Cyrix 6x86 PR233MX with 64MB of RAM, EIDE hard drive 2.5 gbytes (Fujitu I think, don't feel like opening the case), Amptron 8600 motherboard. Linux 2.2.0pre4 kernel. No problems here, checksum was the same each time.
My god, how long does it take to fsck such a beast? Unfortunately, I haven't looked into the journalled filesystem that's supposedly available for Linux (I think it's commercial), but a journalled filesystem is exactly what you'll need for this. Even with a UPS, hour-long fsck times are not my cup of tea.
-Jake
--
Jake
A quick amazon.com search would have revealed the title:
Practical File System Design with the Be File System
by Dominic Giampaolo
From this book, you could literally write your own compatible implementation of BFS for Linux. The question is: would BeOS compatibility be worth missing the opportunity to create a new filesystem tuned for what Linux is used for? The nice thing about dbg's book is that he covers the reasoning behind every decision that he made when developing BFS. Clearly, some of these decisions are closely tied to what BeOS is being targeted for (a single-user power desktop for media professionals), rather than what Linux is most often used for (a multi-user Internet server).
-Jake
--
Jake
I've got various linux boxes here with everything from 486's to PII's.
;)
For giggles I decided to run the test on my 34G IDE stripeset (2 17G drives). I used a 100M file instead of 10M since I have 64M of ram.
Everything checked out 100% okay after 40 sums.
I would say change BIOS settings / CPU Clock speed to something very conservative and re-run your reliability test. Once everything checks out then you've fixed your problem. Then you can start bring speeds, etc up to find out what breaks what.
I've seen problems like this before a few years ago.. Intermittent failures on a news server I ran.. Started with Linux, went to FreeBSD and finally built a brand new box and the problems went away. I would say that your problems are *definitely* hardware. Overclocking your cpu/memory or failing cpu/memory/drives.
Also IHMO, using Windows 95 as a test of hardware is like using an 85 year old lady to test drive an indy car.. Of course nothings going to go wrong at that speed.
-Jerry (jasegler@gerf.org)
A journaling filesystem is not the same thing as a log structured filesystem.
A journaling filesystem is any filesystem that keeps a meta data transaction log so that it can be restored to a consistent state quickly by replaying the log instead of checking every file in the filesystem.
A log structured filesystem, on the other hand, is a filesystem that places all disk writes on the disk sequentially in a log structure, which drastically improves file I/O performance when you have total rewrites of a large number of small files. The log is written into garbage collected segments that gradually free up the room taken by old file versions.
I think if you really need data sets over 4GB, it should be possible to split it over more than one file in your application. The kind of overhead this would give could be smaller than the overhead you'd get from a 64 bit file system, since it would be tailor made for your application. Once you have this flexibility in your system, users that would like to use multiple disks could also benefit from the possibility.
Of course, people with big-ass disks and high uptime requirements need that journalling crap. And they'll have it. So don't be dissin' ext2!
fish and pipes
... Please excuse the stupid question here, BUT:
How does a filesystem of this type allow for a 3x sequential write speed improvement?
I understand what the journaling part is describing, but don't understand how this would be that much faster. Especially under a really heavily loaded server.
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
I read that it can handle volumes of over 1 terabytes....does support for this exist? I think it is a 64-bit journaling FS......seems pretty nice, but I haven't played with BeOS in quite some time...any help out there?
Who is the master of foxhounds, and who says the hunt has begun? -Pink Floyd
Note that I'm a FreeBSD person; all of this from theory, as I've not run Linux for anything serious for a couple of years.
If you run this using the default parameters and get an unplanned shutdown (crash, power outage, whatever), you are likely to get minor file corruption. To get correct behaviour, you should mount the filesystem in sync mode, and rely on the underlying RAID setup to handle write caching if you need it (as this remove one failure layer).
You will also want to modify e2fsck to avoid silent data corruption. e2fsck will (or would, the last time I was in a discussion with the author on these issues) handle a block that is shared between two files by duplicating the block.
This silently corrupts at least one file. You will probably want to change it to delete both files, possibly making that an interactive question. (Deleting is the default action on the *BSD fsck, BTW).
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
Linux and traditional *BSD has choosen different policies here; Linux somewhat gambles with the users data and security setup as a tradeoff for faster metadata updates and lower code complexity. This tradeoff is probably OK if you're only going to use it on a normal workstation, without any critical data on it; I guess it can be OK in some server apps too (though I wouldn't do it). *BSD does things "by the book", guaranteeing metadata integrity (and thus avoiding data leaks, and keeping POSIX semantics for e.g. rename). Note that the traditional BSD tradeoff is NOT the same as Linux 'sync'.
The latest development on the BSD side of this is "soft updates", which is safe without the speed penalty.
Now, back to the original poster:
"Deleting is the default action on the *BSD fsck" Oh yeah, I didn't really want those files. They take up too much space anyway. After fsck destroys my data I will have room for more!
I'll take "maybe corrupt" over "kiss your files goodbye" for sure.
We're not talking "Maybe corrupt". We're talking of at least one file being corrupt, and we're talking of the possibility of private data crossing the protection domain between user IDs, and of wrong data or code migrating into setuid programs.
For some applications, it might be an OK tradeoff to silently corrupt one file to potentially make another file OK. However, it is not OK for any of my applications - I need to know that the security policies for files are held; if I can't know this, I want to restore from backup, rather than keep running with corrupt files.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I have a 38 gig partition on netware and it take about 6 minutes.... raid 5, mylex 960 32 megs of ram.
"Think of it as evolution in action."
Heh, I know of a Netware server that mounts a 50GB volume in the blink of an eye :-) Seriously, its less than a second.
------ Bryan Batchelder Center for Information Technology Stetson University, DeLand, FL http://www.stetson.edu
Dang, the ftp site with the patch gives a 'can't set guest privileges'. Anyone have an alternate site for the >4GB patch? It isn't at linuxmama...
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
It's callled NSS - Netware Storage System. I think it's journalled. I know it's similar to Unix filesystems, in that it doesn't matter where the data is physically, it all looks to be on the same volume. And it is REALLY fast. I mounted a 32 GB volume in about 2 seconds (on a Xeon 450 though).
A year ago when I was working on an AIX system and investigating their new support for file sizes over 2Gig (not 4Gig), I remember it was a bloody pain to switch over. Not only did you have to rebuild your file system and recompile ALL of your applications with the new libraries to get them to support the greater file sizes (I don't remember if you had to recompile apps that didn't care about large files), but once re-compiled, you couldn't use the same binaries with older file systems. On top of all that, there was a significant performance hit (10% to 20%) on file I/O.
Again, I don't remember all the details, but in the end, we decided it was far too painful to implement the changes in our application. YMMV.
Your Servant, B. Baggins
Yea, I've never needed more than that 640k I got in my machine anyway... all the rest just sits there.
--------------------
Endless Loop ; see Loop, Endless
Loop, Endless; see Endless Loop
Ah.. that would be nice.. wouldnt it? goodbye to ext2
--
Not only are disk-writes faster on journeled file-systems, there are also such things as journeled operating systems.
That is, if you turn the power off and turn it on, the entire OS comes back on to a state within a few minutes of where it was. One example that looks interesting is EROS.
I have not seen this one in operation, but there are theoretical arguments for their speed claims, and (as they say) it is theoretically impossible for *any* OS based on access lists (such as Unix) to achieve the same level of security that a capability based system can. (Note, I said "can", not "does".)
Regards,
Ben Tilly
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
If you're netware server crashes that much you have a problem. It can easlily be hardware or an errant NLM or running your backup during file compression.
:)
I routinely see netware servers that have uptimes of 400-600 days.. record is 900 days so far (took a polaroid of that one).
If you want some help with your system, I would be happy to help you wih your problem for free. You can contact me at dminderh@baynetworks.com if you'd like.
The new file system in netware 5 will mount & vrepair 1.1 TB in 15 secconds (that's the largest I have seen..I'm sure it will do more..)
And your mount time isn't that bad. Chrystler has a 500 GB volume that takes 22 hours to mount
If our testing of GFS, we have created ~108 GB filesystems (12 9GB disks software striped together). The only limit in the file system size is 1TB (which all Linux filesystem share).
GFS is a 64-bit filesystem. It supports files up to 2^64 bytes in size (on the alpha).
It is much faster than ext2 for moving around big files.
GFS will support journaling by the fall.
http://gfs.lcse.umn.edu
Since you were running NTFS on that size of file system, why do a chkdsk? NTFS is a journalled filesystem, so there is really no need - and of course journalling is designed to avoid long fsck's.
NT may have its faults, but NTFS is not bad in this respect - Linux does not yet have a widely used journalling filesystem that I'm aware of.
Out of disk space is the fastest way I've seen to crash a Netware server. At one place I used to work, the default mailbox location was on the system volume. Once it was full, BOOM! the server was dead.
I don't want to sell anything, buy anything, or process anything. I don't want to sell anything bought or processed...
We are about install a central machine that
runs NFS, sendmail, DNS, NIS, httpd for internal
use, gnats for around 60 users. Here is the
plan. Two identical machines with 512M ram and
9.0G disks with OS installed. One machine
would be running as NFS server and the other
machine would have all the servers sendmail,
DNS, NIS etc. The NFS server is connected to a diskarray with 7 18.0G disks and a backup
tape autochanger. I want to leave one of the
disks as a hot spare. I would like to write scripts such that if one machine fails, the other can take over by just running a script.
It is the RAID part that is not clear to me. The
last RAID I checked was Veritas on Solaris which
was a major pain in the neck to manage. Don't
know if managing RAID on Linux is any simpler.
I am inclined to wait till RAID becomes a standard
part of Redhat. Until then, I would rather
depend on the tape backups than
Linux RAID support.
I am curious to hear any experiences on people managing large file systems 100G+.
BTW, I haven't still figure how to use our
Exabyte autochanger effectively with a GPLed
backup sofware. Exabyte tech support wasn't very
useful.
Ramana
While there aren't any effective GPLed solutions for using Exabyte (or any other SCSI/Medium Changer unit, for that matter) libraries and autoloaders under Linux, I've been playing around with 'em quite a bit lately, with some success.
Drop me a note: johnbar@exabyte.com
Thanks for the compliment. I'll pass it on. ;-)
- jmb. / exabyte corp.
If the system fails during a write to the journal, I believe that the whole operation is regarded as failed, and what's known in database circles as a ROLLBACK occurs... That is, since the disk operation (e.g. unlink) couldn't be completed, it's not done at all, and thus not left half-done and messy.
IIRC, isn't it NOT the OS, but rather the FS that must be 64-bit? I know NTFS is 64-bit and can handle files over 4gig (I've seen it). And, we all know that NT isn't 64 bit (yet). How it does it I am not sure - need an NTFS reference manual OR the MS source code. Fat chance of that...
;-) Who knows where they are?
I kinda have to suggest this (shrug), but why couldn't we get the NTFS driver bulletproofed (r&w)?? Other than the anti-MS reason, NTFS isn't a bad FS (and is proven) and there is already substantial work done with it... It'd be great for that "Hey, NT admins, come to Linux?"
But, then again, if people like Tweedie from RH working on designing ext3, why bother with NTFS??
L8r,
Justin
Mu. P.S. The address you see is real. =)
No, you don't. Not if you compile the module yourself. Try arla, the free AFS client.
And arla provides an AFS client for free.
Big file systems are great when they work, but FSCK is a nightmare. We have 24 9.1 Gig Drives on a three channel DPT controller. We tried it as a single volume, but weird things happened with the DPT firmware.
We originally used this as a Usenet news server. We tried 24 seperate volumes to have the maximum number of spindles, but Linux has a limit of 16 SCSI drives in the 2.0 kernels. We ended up creating 12 2-drive stripe sets. (no redundancy) We then created 6 partitions. 5 that were 2 gigs in length, and one with the remainder. We used a patch to allow the partitions to be handled as 2 gig files. This was very fast, and had no FSCK issues as there were no file systems. If a few articles were mangled because of a crash.....
We ended up outsourcing our usenet service, and had this server to reuse. We created 3 volumes of 7 drives each, along with 3 hot spares. (One hot spare in each external drive chassis) Each volume is ~50 Gigs in size. One thing we have found is that if we HAVE to fsck the whole thing, (150 Gigs) you need about 4 hours. The PCI bus just doesn't have the bandwidth to check huge volumes in a reasonable time. We end up checking "/" and mounting it rw. We then mount the rest of the volumes "ro". We can then restart basic services (mail, web) and continue the fsck on the read-only volumes.
It's a balance you have to strike. If you really need that large of a file system, understand the time to restart. For us, just a basic reboot takes 12 minutes. With FSCK, it's ~4-5 hours of time to babysit. If you don't need that much space, look at setting up several individual file servers. It will help spread the load.
For robotic changers, one of the best solutions I've seen is Arkeia by Knox Software. www.knox-software.com. It's commercial, and expensive, but worth the money if you need large-scale backup.
Wait... I missed something. When did we get files over 2 GB?
AFS, the Andrew File System, is the file system used to handle Carnegie Mellon users' home
directories, including the home directories of all new accounts, as well as the bulk of system
programs run by users.
Just wanted to let you know. Am at Carnegie Mellon Univ which developed AFS. We are currently using it with 1 Terabyte of space just in our Univ. MIT and U of Mich (Ann Arbor) are among the other colleges that also use it.
I know this sounds ignorant, but what is a journaled file system. An explanation or link would be appreciated.
..
talking windows users is where I draw the line
Tis better to be silent and thought a fool, than to open your mouth and remove all doubt --Abraham Lincoln
Actually IIRC journalling filesystems still require fscks. The process is just supposed to take a very short time. Besides, if you weren't supposed to run chkdsk on ntfs, why would they give it to you? And if ntfs is a journalling fs, why did it take 3 days? MS is obviously doing something (else) wrong.
-matt
Gee, too many people here act like RAID means totally reliable. It doesn't. RAID controllers go wrong; power supplies go wrong; many RAID controllers don't handle power outage properly (there is no such things as an "uninterruptable" power supply) as they have no battery support for data in transit; RAID controllers with battery support don't properly detect when the batteries have died, and won't provide any real support when their big day comes; hosts go wrong and scramble their disks; and even the best operating systems can go a bit pear shaped some days. There is also the good old "some idiot just typed a dumb command and wiped thousands of files" issue.
I'm not saying RAID is a waste of time. It improves reliability a great deal, and the better designs make things go faster. They aren't perfect, though.
Backing up a monster partition is a pain in the neck. If you have a monster database you have little choice, but smaller partitions make life easier.
I did your test.. and my results follow:
10485760 Jan 18 22:00 bigfile
after 30 runs of sum, _ALL_ checksums are the same
41865 10240 (My setup is an ASUS TXP4 with Maxtor 1.2 gig EIDE.
True, it's not ultra DMA, but as you can see, it
checks out fine here.
no doubt throught some kludgy shift register crap or something similar. x86's memory arch is the most horrible i've even heard of.
I tried it and got the same checksum every time (Tried both checksums 4 times).
I'm using a AMD K6-2 on an Asus P5A-B motherboard (uses Alladin (Ali1xxx) with a Quantum Fireball ST3.2A.(UDMA 2). Don't know the transfer rates.
Greetz, Takis
Actually, at least Solaris 2.5.1 doens't support over 2GB files, according to Sybase, and believe it or not, but NT does. You can have a 32GB device (ie file) for Sybase under NT
I am interested in this as well. I am currently in the process of setting up a 180GB fileserver. I am using dual redundant CMD RAID contollers and 10 - 18GB UltraWide SCSI drives. The RAID provides a mechanism to create partitions that show up to the OS (linux) as individual drives. This is done by giving each partition in the RAID set it's own LUN. The bigest RAID partion I have made is 80GB. I am booting off the RAID set as well(no hard drive in the server box). I have had no problems so far. I also noticed that it takes quite some time to mount the larger partitions. One thing you might want to experiment with is varying the bytes/inode and also the reservered blocks percentage (man mke2fs). On large partitions you can waste alot of space if you keep the default 5% reservered blocks percentage.
I'm interested in info on using dat changers under linux. Is anyone doing this? If so what changers are supported?
The machine I'm sitting at has an APS Technologies changer attached to it, of unknown model. The tape changer says "DATLoader600", but that is not an APS name.
Here is a link to the APS website.
All this talk about RAID makes me yearn to run Linux off our cool new Adaptec ARO-1130SA and AAA-130SA RAID controllers. However, to the best of my knowledge there are no drivers available yet. Has anyone else had luck getting one of these critters to run under Linux? If so, how'd you do it?~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Norvelle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Norvelle
Cre
Linux 2.1.132
Intel p255MMX (Yeah, it's overclocked, bus is running at 75Mhz.)
128Mb edo, bios default for 60ns in my award bios.
(simms are 4x 32Mb, 2x TI and 2x Panasonic)
Mobo: Asus T2P4 Cache: 512Kb
HDD's:
1.0 Gb samsung pio-4
2.5 Gb bigfoot pio-4
4.3 Gb bigfoot pio-4
On all the disc the outcome was the same,
I "summed" for 30 times each disc.
I also tried it on my nameserver,
Linux 2.0.36 + egcs patch
AMD 386DX40
Motherboard = unknown
8Mb "topless" (8x1Mb)
420 Mb Seagate
BIOS MEM Setting: as conservative as you can get
I tried it 20 times here, also no difference in
sum.
Weird shit happenin' in yer machine...
Try other ide cables, I had problems with that in the past, my hdd's used to spin down (a bit) click and the get up to normal speed again. Bad connectors caused the hdds to reset once in a while, this cost me some write and read errors including some badblocks! (my system tried to read/write while the heads were resetting -> the "click" sound).
Anyone here who has/had this problem too?
.. in older versions of netware, i.e v3.x or v4.x it really takes ages. But take a look at Netware5 and the new file system... it rox!
/z80
-- http://z80.org - all opinions, all the time --
At my work we have been toying with an 18GB RAID0 partition under Linux. We would like to perhaps stick even more disk on it, however I don't know of a good GPL backup package. Does anyone have any pointers here? I don't think that a simple dump or tar will cut it.
Cheers,
Cam.
Cameron_Hart@design.wnp.ac.nz