Re: FAQ
On 08/04/2000 09:54 -0400, Theo Van Dinter wrote: The usual suggestion is: bzip2 -dc filename.tar.bz2 | tar -xf - or use bzcat, which is exactly the same as bzip2 -dc... -- +--+--+ | Tim Walberg | [EMAIL PROTECTED] | | 828 Marshall Ct. | www.concentric.net/~twalberg | | Palatine, IL 60074 | | +--+--+ PGP signature
Re: problem: unexpected inconsistency
Sounds to me like you either: 1) initialized md4 after there was already a live file system on it, or 2) initialized md4, then used dd to copy a file system onto it, and you didn't take into account that the raid superblock takes up the last bit of the partition on which it's built, meaning that the md device size is slightly smaller than the original partition was. I would suggest backing up the data, re-running mke2fs on md4 rather than on the underlying partition, then restoring the data. tw On 04/12/2000 12:05 +0200, Patrick Peck wrote: hello, i'm trying to get software-raid 1 started on my machine. kernel version 2.2.14 + ide patch + raid-0.90 patch so far, i've succeeded in setting up the array using mkraid. when booting the system, the raid partitions are auto-detected, but mounting the filesystem fails with the following error: /dev/md4: The filesystem size (according to the superblock) is 2671444 blocks. The physical size of the device is 2671424 blocks. Either the superblock or the partition table is likely to be corrupt. /dev/md4: UNEXPECTED INCONSISTENCY, RUN FSCK MANUALLY i did 'fsck /dev/md4' but it did'nt help... thanks in advance, patrick End of included message -- +--+--+ | Tim Walberg | [EMAIL PROTECTED] | | 828 Marshall Ct. | www.concentric.net/~twalberg | | Palatine, IL 60074 | | +--+--+ PGP signature
Re: autorun
On 10/27/1999 10:07 -0400, Fernandez, Richard wrote: Hello, I've been able to set up raid 1 for my /usr /var and /usr/local partitions on RH6.0 I've been lurking in the list for a while and I keep seeing references to setting the partition type to 0xfd for root-RAID. I feel dumb asking the question 'cuz the answer must be staring me in the face: How do you set the partition type to 0xfd? I don't see any reference to "fd" when I list the Hex codes (fdisk v2.9n) To quote a popular shoe maker... "Just do it". Never mind that fd isn't in the list; when it asks for the new partition type, type in '0xfd'. tw -- +--+----------+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: RAID controllers under Linux...
Of course you can use all 4 primary entries, but you can't use logical partitions with this method, because you can' t copy a partitioning scheme with logical drives in an extended partition with just a single dd ... Unless the logical partitions are also identical and in the same order. I've done this on my system - two identical drives, all partitions are RAID1s and laid out exactly the same, and it works fine. You're right, though, if you want to use different extended/logical partitions (or even primary) partitions, you can't just dd the partition table. You could, however, probably write some gnarly little script to parse 'fdisk -l', merge the partition tables and write them out to the second disk (yuck... can't believe I'm suggesting that - just shoot me now...). tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: 71% full raid - no space left on device
On 10/14/1999 09:22 -0700, Thomas Davis wrote: Stephen Waters wrote: Thomas Davis wrote: Stephen Kennedy wrote: Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 155545 95652 51863 65% / /dev/hdc6 5653028 232 3143636 41% /home /dev/hda6 2229516762396 1353864 36% /usr /dev/md1 1011800681344279060 71% /usr/src /dev/hda1 3310904 2522112788792 76% /dosc how about 'df -i'? you could be out of inodes.. if one were out of inodes, how would one go about resolving the issue? backup filesystem and reformat w/ more available inodes? preparing for the worst, You've got it. I don't know of any Unix FS with dynamic inode allocation.. Is there one? Veritas' VxFS does, but, alas, there's no Linux port. Works great on Solaris, though. tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: resync after disk failure
On 10/12/1999 16:56 +0200, Kay Salzwedel wrote: Hi folks, How long does it take to resync a RAID5 array after a disk failure? Unfortunately, I have just two disks on my box (OK, I got tree on it but one is so packed that I can not use it) so that I cannot try for myself. This really depends a lot on the size and speed of your disks, and the amount of other activity going on on your system (resync is done at lower priority so that other I/O activity is not stalled). Can't tell you much more than that. Curious, why would you use RAID5 when you have only 2 disks? RAID1 would give you better performance for no cost in usable space in that situation... Please cc to me 'cos I'm not in this list. Regards Kay -- Kay A Salzwedel Heinz Nixdorf Institute University of Paderborn Germany -- E-Mail: [EMAIL PROTECTED] Tel.:+49-5251-60 64 58 End of included message -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: Booting Root RAID 1 Directly _Is_ Possible
One method I've seen on another platform (Solaris/Veritas) is as follows: 1) boot loader knows about a list of the various components of the boot RAID device (accomplished via eeprom on SPARC) and will attempt to boot from the first of these it can talk to 2) first component is accessed in read-only mode (thus not invalidating any RAID data) in order to load the kernel far enough to go through the device detection/configuration stages 3) after RAID devices have been detected and configured, boot/root file systems can be re-mounted read/write I'm not real familiar with the LILO or kernel-boot code in Linux, so I don't know what kind of work it would be to implement something like this, but I do know that this process has worked extremely well for RAID1 root filesystems. It wouldn't work very well for RAID0 or RAID5, I'm pretty sure, but I've usually set up a relatively small RAID1 root filesystem and used RAID5, RAID1+0 (or 0+1) on other larger file systems. The only major problem I've gotten into with this is when the root filesystem gets corrupted enough that the kernel can't be found on the booted component, but hopefully that's a **very** rare occurrence. tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: raid0 vs. raid5 read performance
On 07/30/1999 08:51 -0700, Roeland M.J. Meyer wrote: Then what I get from this is that the fundimental unit of measure is kilo-bytes (KB/1024 bytes)? Further, that I will have to write up various cases? Okay, I'll do it. Case for normal generic file system usage and a case for RDBMS usage. These will include separate considerations. It'll take a while because I have to interleave it with my WHOIS server project and my day-time job. I might ask the list for certain empirical results, as I run into the cases. Yes, I think it is important, especially for ORDBMS users. I have both Oracle8 and PostgreSQL. If MySQL users can identify themselves now I will ask them for case studies later. End of included message Actually, it might be useful to consider several different cases (you mentioned 1 and 4, but there are a couple other common cases): 1) RDBMS raw block device usage 2) small-file file system (i.e. news server) 3) large-file file system (i.e. images, archives, data warehousing, ftp servers) 4) general purpose file system (somewhere between 2 and 3) The differences boil down to optimizing for small IOs vs. large IOs or (less) optimization for the general case. If I had the hardware to do it, I'd generate as many empirical results as necessary for you - I've done this before (but using Solaris/SPARC with Veritas Volume Manager, and at a previous job - I don't have access to that kinda stuff at the moment). I/O optimization was pretty much my sole purpose for living for a year or two... ;o) tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: raid0 vs. raid5 read performance
On 07/30/1999 09:34 -0700, Roeland M.J. Meyer wrote: Actually, it might be useful to consider several different cases (you mentioned 1 and 4, but there are a couple other common cases): 1) RDBMS raw block device usage 2) small-file file system (i.e. news server) 3) large-file file system (i.e. images, archives, data warehousing, ftp servers) 4) general purpose file system (somewhere between 2 and 3) Data warehousing is the RDBMS case, usually done with exactly the same hardware and software, but different optimizations. The schemas are, of course much different (star queries are a PITA!). Much of it depends on how the RDBMS is implemented. However, I don't think anyone does RAW Don't know about under Linux, but I know of a number of sites still using raw for databases (granted, I don't think any of them are on Oracle, they're all either Sybase or Informix). anymore. Image archives, for anyone doing a production implementation, isuslaly served up as BLOBs, under an RDBMS (back to the RDBMS case). I wasn't thinking of images only in the graphical sense - we've got a server where we keep large images of databases (kind of a fast rollback/recovery solution - don't ask). This gives us case 1 and 2 as special/rare-use cases and drops RDBMS and FTP servers into case 3. What do you think? Another way of looking at it is: 1) constant (or near constant, anyway) medium IO block size mostly sequential access (corresponds to 1 above) 2) small random access (corresponds to 2 above) 3) large sequential access (3 above) 4) random size random access (4 above) I guess I might concur that 1 may have features in common with any of 2-4, depending on what exactly the DBMS is doing - small vs large tables, small vs large updates, etc. Where 1 tends to be different, is in the fact that the kernel buffer cache is usually bypassed in this case, so the characteristic I/O patterns may be significantly different because of the use of different caching and write gathering algorithms. I don't know if there's a big enough difference to worry about, but I don't know there isn't either. That's why I always recommend benchmarking several different configs. I still think 2-4 are sufficiently different, though - 2 and 3 are very optimized for particular purposes, and 4 is less optimized, just designed so that everything works as well as can be expected. -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: raid0 vs. raid5 read performance
On 07/29/1999 11:18 -0400, Jan Edler wrote: I don't buy this; the atime updates should be subject to caching, and not get written to the disk more than the update daemon (kflushd or whatever) forces. True, if there are a small number of accesses, but I have seen many cases (for example running 'find . -whatever' on a large file system consisting primarily of many small files) where there are sufficient accesses going on to keep kflushd/update/whatever busy enough to actually impact read performance. Granted, that may not be everyone's usual case, but it does happen. This is one of the reasons I will personally not recommend putting a very busy news server on RAID5 - the expires can easily kill a machine. tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
Re: raid0 vs. raid5 read performance
On 07/29/1999 10:24 -0700, Lance Robinson wrote: AFAIK: RAID-5 accesses are always in stripes. All disks are read (or written) no matter how small the original read/write request. Whereas, RAID0 can read just one disk for smaller requests. RAID5 does a lot more work for smaller requests. Lance. Haven't looked at the Linux implementation code, but if this is true, somebody needs to be whacked... That's **vey** sub-optimal. For writes, it is most efficient if you can write-gather so that you can write an entire stripe, but you do not need to access the entire row on reads - there should be (almost) no overhead for reads, unless you've already lost a disk and are having to calculate data from the parity. For example, consider a 3+1 RAID5 (4 drives) with a 1-block chunk size. The following scenarios are the way I see things should probably happen (assuming that Drive3 is the parity drive for this row of chunks, and reads/writes are aligned at the beginning of the row - for other situations, the access needs to be separated into separate events that are all the equivalent of one of these): Event Drive0 Drive1 Drive2 Drive3 Reads Writes --- --- --- --- --- --- -- 1 block readread1 0 2 block readreadread2 0 3 block readreadreadread3 0 1 block write write read/write 1 2 1 block write write readreadwrite 2 2 2 block write write write read/write 1 3 2 block write write write readwrite 1 3 3 block write write write write write 0 4 Note the alternatives to the 1 and 2 block write scenarios that avoid having 2 consecutive I/Os on the same drive (which must necessarily wait for an entire rotation of the platter, unless you are using the drive's write cache, in which case you're just asking for trouble for a number of other reasons) Also, for any of the writes, the parity cannot be rewritten until enough data is available to recalculate it - either by reading the drives that are not involved in the write or by reading the parity and calculating it based on the drives that are being written, so assuming writes can be performed in parallel, and a write takes W ms, a 1 or 2 block write must take at least 2W ms to complete, where a 3 block write can be done in 1W - this is why large (i.e. full-stripe) writes are better under RAID5. Note that none of this takes into account any RAID book keeping that has to be done, either. Again, I haven't looked real close at the Linux implementation, so I don't know if it's doing any dirty region logging or anything, which just makes the whole analysis that much more complex... Hope that's useful info to someone... (Also hope I haven't goofed something up there... ;- ) tw -- +--+--+ | Tim Walberg | Phone: 847-782-2472 | | TERAbridge Technologies Corp | FAX: 847-623-1717 | | 1375 Tri-State Parkway | [EMAIL PROTECTED] | | Gurnee, IL 60031 | 800-SKY-TEL2 PIN 9353299 | +--+--+ PGP signature
