mister_z

Used to be Dell, now moved to 100% HP. Excellent Linux support, good hardware, breaks less often that Dell has for us. YMMV

For a database that is read-mostly, RAID 5 or 6 is fine. My organization uses it all the time for low write/delete/modify databases. And we use RAID 6 for much of our data warehouses (tempspace and index rebuild areas excepted). RAID 5 is only slower during write ops, not read ops. So consider the usage. RAID 1 and it's big brother RAID 10 we use for fast transactional systems, beginning with the log space (since that's written to with every write op), then for the temp space (large sorts, etc), then as needed for high change rate tablespaces. For spindle capacities > 600GB, we go to RAID 6, since the hotspare rebuild times start to get longer, and we really don't want to lose another drive while one is rebuilding. Else it's "Hope the backup set is current," and "Tell the users it'll be down till the restore finishes." Also, don't confuse throughput/bandwidth with access time. They only correspond when there are enough users active, and then only roughly. Without a demonstrated bottleneck, adding more spindles to a RAID set (thus raising the stripe size) means more users can get to data in the same time, but not necessarily that the same number of users can get to the same data faster. Lastly, remember the hot spares. Our rubric is 1 HS per 30 disks in service if the hot spare can take over for any other spindle in the same VNX or VMAX (my teams manage several data centers with rather sizeable SANs in each). If you do not have hotspares, you MUST HAVE ACTIVE MONITORING watching for failures. I have seen too many organizations lose a disk in a redundant system and not know it until a second one fails. "Oops, this is going to suck." As I recently explained to a colleague in another division, my preference (not always possible) is to start as small as possible and "watch and grow" the system as performance data becomes available. I advised him to keep 30% of his space in reserve and adjust its placement as he learns more. Best of luck.

Linux Journal Archive 1994-2012 on DVD. ~ $40.00 USD All the back issues, searchable. NOT a textbook, but rather an exploratory journey in a series of bite-sized pieces. Issues focussed on System Admin, Programming, Security, etc. I've been doing Unix a long time, and have done Linux since Slackware, and I still gain nuggets of wisdom from it (I keep in on a USB key with me, and I'm making it a goal to read every article in every issue eventually. Something to do over lunch every day.) Because the truth is, *nix is so big, few of us even have the time to explore all the corners of it, and so there's always something new to learn. Sometimes even in the articles I thought I'd have no interest in. Cheers, Oh, and if you like the archive, consider subscribing to keep up with the newer stuff.

Well, there are many ways to hose Linux -- as root. But if you routinely run things as root, you deserve what you will eventually get. You're basically saying "Yes, I know the gun is loaded, but I want to muck about with it anyway just to see what happens." That's why sudo was invented. If you have to sudo the command, you'd best understand what you are doing. If you are operating as a standard user on a well-managed system (i.e. one with quotas, limits, etc), there's little you can do to screw up anyone save yourself. As root ? You can delete the entire file system, destroy the volume manager information, reformat hard-drives, just about anything.

FWIW, you can get Fedora "spins" with different interfaces, see Fedora Spins, including KDE (my preference), XFCE, etc. And with the base install, you can choose either Gnome 3 or KDE, and tyou can even install the cinnamon variant. Cheers.

Backup: Hmm, depends on standards and the pocket depth. My day job has corporate standards, so NOT using Symantec NetBackup will get people in trouble. So the first question for the interviewer is "Do you have any standard for backup software ? Legato ? TSM ? NetBackup ?" In my pro bono work -- smalll non-profits, etc, for linux installations with more than 1 server, I recommend AMANDA overall. It takes some setup -- but that's why there are administrators. And iits flexible, resilient, and it just works. You can set it up to use common tape devices, including hand-me-downs. Or your can use SATA docks and dump to disks. Combine with LUKS volumes, and you have encrypted backups as well. As for MySQL -- one way is to read-lock the database for consistency and LVM snapshot the volume that the data files reside on. Release the read lock and the database can go back to happily accepting transactions while AMANDA backs up the snapshot volume. In earlier versions of MySQL (5.0 and earlier) this was the only way to get an "almost online" backups in a 24x7 environment. Security procedures ? That can fill a book by itself. And does. The major point about security is this: If it's highly convenient, it's probably insecure. Lock out root ssh logins ? But it's way more convenient to log in as root directly -- why do I have to use sudo ? The DBA team needs root access. And then know what they're doing. I'll just give them the password to save time. Enforcing password changes every 90 days ? What a pain. If I put in password complexity requirements, everyone will be so annoyed at me.\ Creating a cron.allow ? Are you kidding ? Then every time someone wants to run a cron job, I have to add them to the file. Understanding and reluctantly embracing the security mindset is much more important than memorizing every rule. If you embrace security, you can google to build an effective security baselin, and you may even enforce it. Good luck.

First, you need to decide what you are trying to back up. The first step in disaster recovery -- as I evangelize often enough -- is deciding "what disaster am I preparing for ?" (You'd be surprised how often that question gets overlooked. And then you have 4 blind men describing the elephant AFTER many plans have been created.) Anyway, are you trying to be able recover the entire laptop ? You do need some way, unless you want to re-install from scratch, a major pain. I consider this part a job for CloneZilla. Periodically. And a USB drive is an excellent place to put it. Plug in the USB drive, boot from a thumb drive, answer a few questions, let it chug. But you will want to protect daily work as well -- say her home directory. Are you okay with working at the command line ? For my wife's laptop, I use rsnapshot to dump it to my back-end server. Especially nice since it allows her to recover earlier versions. of certain documents. see rsnapshot for details. Note that while the setup part -- done only once -- takes some ability to work at the command line and to closely follow instructions. But the nightly execution of the backup is a single command -- you can create a 1-line script and link a button, icon, or menu choice to it. Or try a cron entry. As for "getting in," from a remote location, with a Smoothwall and a DMZ, you can portmap to a DMZ server on the orange interface (presumes 3 NIC connections on the smoothie). Use a NONstandard SSH port on the smoothie. No sense making it obvious. Uou MUST use stricr key-based auth (which rsnapshot needs anyway). Do not allow password-based logins at all. You MUST use a forced command with the associated ssh key. Then the only thing the key does is to allow an rsync. Attempts to login are rejected. Read and understand Using Rsnapshot and SSH Now, what did I forget ? Cheers.

1. Does it boot with the new disk removed ? 2. Is there a controller BIOS setup screen (Ctrl-A at boot up, for example) ? 3. Is this a "regular" server with multiple drives, software RAID, and linux loaded ? If not, what is the manufacturer ? One thing in my experience that matches this is a system with software raid, that is trying to boot from a hard drive that was never bootstrapped. One can start up a system from drive 0. install Linux on software RAID, and think "Aha! Now I am safe!." But without loading LILO or GRUB into the boot block of the second physical hard disk, if disk 0 fails, the O/S has nothing to boot from. Another alternative, presuming SCSI disks, is the need to set the disk controller BIOS (e.g. the Adaptec 29160 or what have you) to boot from the second SCSI ID if the first one has failed and been replaced. Otherwise, the BIOS goes to the first disk, which was replaced and has no boot block. and fails to boot.

First, a caution: RAID is not a substitute for backups. It's an availability mechanism, not a disaster-recovery option. Multiple failures can and do occur at times, as our Windows administration team has found out. And more importantly, RAID does nothing to protect against inadvertant overwrite or erasure. As RAID does reduce the chance of catastrophic storage failure, it can be used to somewhat offset risk of a reduced frequency of backups, but it does not take the place of them. Put another way: With RAID 1 mirrors on my home server, I may be satified with only a weekly backup instead of a daily, since the chance of multiple disk failures is lower -- but it's still there. RAID 1 is mirroring, with or without a hotspare. The minimum is 2 disks, maximum of 3 if you can afford it. Performance is very high, since the same data is written to both disks and no calculations are necessary. But the effective total storage capacity is one half the total physical storage, or even one third if you use a hot spare. So it's more expensive. I use it (in my day job -- IT Architect) when performance is extremely important, when I only have 2 disks, or when I only have 2 or 3 I/O channels to use. Without a hotspare, when a disk fails, you stay in operation running on the remaining "mirror half," although you have lost all redundancy. Generally, you can hot-swap in a replacement drive, and the array starts chugging, reading from the good" disk and copying blocks to the new disk.. With a hotspare, this happens automatically to return the array to a state of full redundancy as quickly as possible. RAID 5 requires at least 3 disks. It breaks up the data "stripe" into 2 or more chunks (or "blocks"), and writes one block to each disk. The remaining disk gets a parity block, calculated from the data in the other blocks in the stripe. Each stripe uses the "next" disk in line for parity, so that the parity is spread over all the disks. Upside of RAID 5 is less "wasted" space -- only 1 disk's worth of space is used for parity overall, so an 8-disk set (sometimes called a "seven plus parity" or "7+P") only "wastes" 1/8th of the space. Though I'd usually set that up with a hotspare, as 6+P+HS. Downside of RAID 5 is calculation overhead. First, if you are writing a ton of data, say a transactional database, every stripe requires a new parity calculation. For most users, this is not a big deal, which is why RAID 5 is a sweet deal most of the time if you have enough resources to support it. When a disk fails in RAID 5, the system recreates the "missing" data for the stripe by calculating from the blocks on the remaining disks. this is called "degraded" mode, and you WILL notice the performance hit then. And when hotspare or replacement disk becomes available, the system begins to read EVERY block of EVERY stripe to recalculate the data to write to the new disk, called "rebuilding" the RAID set. RAID 5's can only tolerate 1 failed disk at a time. As disks get larger, the time needed to rebuild gets larger, so the risk of a second failure gets larger too. RAID 6 "wastes" more spare by storing the parity block for each stripe on two different disks. You can lose a second drive before the first one completes a rebuild, and still stay in business. We use RAID 6 for arrays built on disks larger than 750GB. BUT IT'S STILL NOT A SUBSTITUTE FOR BACKUPS. Hope this helps. Cheers.

I don't know of any slick way. With RHEL, I have to boot off the install CD or DVD and at the boot prompt do linux rescue That will boot RedHat (commercial version of CentOS), and mount the existing file systems under /mnt/sysimage That should allow you to change the root password chroot /mnt/sysimage passwd If there's an easier way, maybe someone else knows of it. But that's all I can offer. Good luck

What purpose are you formatting the drives for ? Typically, when I hear "SAS" I think "server," and that server's disk controller should do it for you. Use the server's controller setup utility (usually in the controller BIOS) to do it for you. For example, the old Adaptec controllers popped a message during boot to "Press Ctrl-A for SCSI configuration utility." Doing that brought up a menu. Our HPs have something similar, though I don't know what the current Dell PERC controllers look like or what key combo they use. If you configure them for RAID, Redundant Array of Independent Disks, see RAID - Wikipedia, the free encyclopedia and if you don't understand that after reading it, post a question and I'll try to answer it. With 5 disks, I recommend RAID 5, either 4+P or, if you can spare the space and the controller supports it, 3+P+hotspare for the best resiliency. AFTER you configure the RAID group, the RAID controller will typically present the RG as one big "disk" to the operating system. The O/S will see this as one big volume for you to use as you wish. Hope this helps

Not sure how your windows shares appear. From a command line, does 'mount' show the file system you have mounted ? If so, and if 'share1' is the only mount named like that, from a script cd `mount | grep share1 | cut -d' ' -f3` should put your script in that directory, in preparation for whatever copy or other commands you want to run. Good luck.

tar -zcvf - some_directory | ssh some_user@some_host 'cat > some_destination_file_path.tgz' Tars, compresses, and copies a directory across servers in one step. There are a number of variations on this command set, I use this one to illustrate the power of SSH since I think it's reasonably straightforward for less-experienced users to understand and adapt to their needs. Rsync can do it even better, but this forms an encrypted tunnel.

Using Clariion from old CX500s thru CX4s, and Celerra/NS NAS. If you demand performance and reliability, I consider them the ones to beat. Disclaimer: I moonlight pro bono for education, my day job is in a specialized offshoot of a large financial instution, so I have deep pockets. I have mutiple SAN farms in a number of states in the US. Never lost data due to equipment failure. My counterparts in the Windows world just lost (temporarily) 11 TB of data due to Dell MD1000 DAS array failures a month ago. Yes, they had backups, but data were inaccessible until the restores (11 TB worth in small files!) were complete. Very painful and embarassing -- and now that the horse is gone, my boss told me to move their stuff to the SAN and get them out of the storage business So reason #1 for a SAN ? Reliability. What you get for the price is redundancy, engineering, and features like scrubbing and performance analysis and improvements. 2. You get better manageability. I have over 100 servers in a typical site. The question "What's the approximate total storage in site X ?" is answered in minutes or less. That may sound trivial until you need to generate budget numbers quickly because the financial picture just changed. And maintaining 15% headroom means when my boss says "How quickly can we . . . ?" the answer is "Right away." This is also an advantage of NAS appliances. 3. You get re-use. When a need disappears, circumstances change, or I just plain goofed on the estimate, I can move storage logically thru re-zoning to meet changing conditions. This is also an advantage of NAS appliances, thru different means. 4. You get portability. If I need to upgrade a Linux server, I provision a new one, and on the appointed day I export the LUNs from one server, import them on the other, and I'm back in business quickly. I could rsync them, to be sure, but that means time spent to do it, sometimes a long time, and also the duplicate disks since the target and destination must be separate. This is also an advantage of NAS appliances. 5. Fiber channel - you get security. The FC imposes an additional security layer. Our Clariions are only accessible thru the fiber, or thru a security-enabled out-of-band network connection. Not all of these apply to schools. In fact, I doubt many schools need more than a well-designed NAS farm. A small Catholic school I know gets along very well with a open-source, linux-based NAS using several nodes. Depends on your size, your appetite, and your need for performance. Best of luck

What issue(s) are you trying to solve ? Performance woes ? Manageability ? Maintenance costs ? I generally don't recommend FC for smaller shops. Yes it's the king of security and performance, but do you really need it and do you want to pay for it ? Some parts of my shops are FC ( we're big on EMC and eminently satisfied ), with multi-TB transactional databases we need the performance. But for 4 of our satellite sites -- with 100% Windows and less that 50 servers in each -- a NAS-based solution (EMC Celeras, in fact) fills the bill nicely and leaves out the complications of additional fiber work. There's already 10G and gigabit and network expertise, so it's been mostly a plug-and-play operation. Several senior leaders "thought" we needed fiber, but I talked them out of it and now they're glad I did. For FC work, if you really want uptime, you'll want two switches, with all critical servers dual-pathed to each in case one dies, and to permit regular firmware updates. That means 2x the number of servers in switch0ports (which you will pay for), some sort of multipathing (EMC PowerPath or similar for Windows or Unix, native multipathd for Linux), and connections to each FC appliance and a dual-port FC HBA in each server. Sketch it out, add up the costs and see if you think it worth it. The NAS alternative is a second GigE NIC in each server, extra GigE blades in your network switches, and a separate VLAN for the NAS traffic to reduce contention. Do you really think you'll overwhelm that ? Do you have severe contention with your existing server-based files ? Coraid makes some interesting ATAoE stuff I've been reading about, but I have no direct experience there. I keep hoping for a new site / new project to cough up some R&D money

Well, RAID 6 is generally excellent protection on its own. Deciding on a dedicated hot-spare depends on the answers to several questions, among them How good is your monitoring ? Will you know promptly when you need to replace a failed disk ? The hot-spare makes up for some less-effective monitoring systems, giving you more time to actually notice it failed before it becomes a crisis. If you have nagios or similar watching everything and emailing alerts, this is less important. How physically accessible is the system ? Do you have on-site support regularly available at least during normal business hours ? If it's a "one person show," does that techie take extended vacations ? Are there weather-accessibility issues ? For remote sites, how long is travel-time ? The hot-spare will buy more time to actually get to the task of changing the disk. But if those are not a factor, you may have plenty of time to swap disks manually. How long to acquire another disk ? If the vendor takes 2 weeks to get another disk, and you don't have a spare on the shelf, you might get nervous in the interim. If you have a shelved spare, or can "share spares" among several teams / locations / schools / organizations. this may not be a concern. How big is the disk / how busy will the system be / how long does it take to rebuild ? The hot-spare starts the rebuild as soon as the failure is detected. If rebuild times are not long (you can test this any time as long as you have a good backup first), then starting the rebuild later rather than sooner is not a problem. Can you stand some small risk of downtime if the unlikely happens ? Probably 'yes' but consider it. You could get a run of bad disks. It's rare, but we lost a pile of them in quick succession some years ago. Our SAN systems were slamming in hot-spares (we allocate one for each 30 disks in service) at a (comparatively) stunning rate. This was a real corner-condition, but the hot-spares earned their keep in that we had zero downtime. How are your backups ? Do you test recovery regularly ? I recently ran into an issue where a specialized backup technology from a really big vendor worked perfectly during commissioning tests. And subsequently during annual D/R tests. Until we grew the LUN size over a certain number of TB. Then it went kerblooey. All the backups were running perfectly, but we were still vulnerable due to a bug we didn't know about. In the end, only you can decide. RAID 6 already goes a long way to being able to sleep at night, you may need nothing else. Best of luck.

Well, if the sole purpose of this appliance is to act as a RAID server, it IS "hardware RAID" after a fashion -- there's a piece of hardware whose sole job it is to maintain the RAID subsystem. Generally, I refer to "software RAID" as that which occurs on a system that is performing other operations as well. For example, a Sun database server using Veritas Volume Manager (VxVM) to perform mirroring between pairs of LUNs. The issue here is the potential for slower performance as the CPU and I/O channels choose between database updates and mirroring I/O operations. No, it's by no means a foregone conclusion that it will be an issue, just that it can be. In addition to the possible overhead of software RAID, there's the setup expertise -- the "care and feeding" part. I agree that VxVM, mdadm, and the like are not rocket science, but plugging in a card and running a vendor utility are even less so. I'd love a Hitachi VSP for every project I do, but I don't have that much budget. I've also done plenty of pro bono mdadm setups with great success (I recommend webmin to remove much of the grunt work). Depends on the money and the skill level. And while I have no experience with QNAP, I would not be surprised to see them using FOSS tools like linux and mdadm. But if I have the right impression, understand they're devoting all the CPU power on that appliance to running either mdadm, NFS, Samba, or some combination of all 3. The CPU has no other work. Hence, you can consider it hardware RAID. In my day job, I have worked with storage engineers from several huge, 3-letter vendors, and been given logins to what were obviously customized Linux-based appliances under the cover. If you're feeling really curious, pull a disk and mount it on a Linux system. See if mdadm can read the header. Ultimately, RAID cards are easier than mdadm, and you don't need much for care and feeding. How many people running mdadm run checkarray or some other tool like that religiously ? If you can afford them, those cards have their advantages. IIRC, mdadm has a limit of 28 devices per array. There are ways around that, but I think then the stock kernel gets confused. I have never used more than 8 in a RAID 5, disks do fail. Then I've used LVM to stripe or "glue" the individual arrays together. But that's more of a personal choice than anything else. Cheers

Descending into geekdom with a senior IT guy. My teams manage storage, and I architect storage solutions for various projects, so be warned. . . Mr. Z's First rule: RAID IS NO SUBSTITUTE FOR FULL AND TESTED BACKUPS. Now, for those who don't want to read further: Chances are excellent that RAID 5 will fill the bill for most educational projects. Short form: It's highly redundant, and the only performance penalty is during write activities. BE CERTAIN you can detect failures and address them promptly, have spares, and you should be fine until the equipment ages. Longer form: RAID 5: Uses a number of disks (typically 3 to 8) to create a "RAID Group." Visualize an 8-layer cake. Instead of a sector on one disk, like a slice of one layer, there is a "stripe," a slice cut thru all the layers. In that stripe, 7 of the pieces contain data, the 8th contains parity information. If you lose one "layer," the information for all the stripes can be recreated as long as all pieces of all 7 other layers remain intact. The parity sector is calculated during a write operation, and is written in round-robin fashion to layer 1 for the first stripe, layer 2 of the next stripe, etc. Disadvantage ? These parity calculations take time and processing power, which is why I do not specify this RAID level for highly "write-intensive" applications like a transactional database with 3,000 concurrent users. But I doubt this is a serious issue in most educational uses. Advantage ? Saves money -- you only need one disk worth of overhead to carry the parity information. But don't get carried away. . . One thing to watch for -- as I mentioned already -- is to be certain you can detect failures promptly. When (NOT "if") a disk fails, you need to discover that and to replace it promptly. The system will typically begin reading every sector of every other disk (called running in 'degraded mode') to recreate the missing data both for user operations and to rebuild the disk when you replace it. IF A SECOND DISK FAULTS BEFORE THE REBUILD COMPLETES THE RG IS TOAST. That's why you replace failed disks promptly, and never put "too many" disks into one RG. I have been consulted after people build RAID 5 RGs with 15 disks, and 4 years later two fail. They ask "what can we do ?" and I tell them to reach for backups. (See my first rule) So, as disks get larger, the rebuild times takes longer. Which leads to . . . RAID 6: Like RAID 5, but the parity information is written to 2 disks in the RG. Advantage: Lose 1 disks and there is no degraded mode operation per say. Lose a second disk during rebuild and then the system shifts to degraded mode. BUT, it's not a disaster. Disadvantage: Higher cost ("wastes" another disk over RAID 5), not all controllers support RAID 6 yet. Also resistant to LSE's Latent Sector Error (LSE) - When a disk has a weak sector but either that data has not been read from, or the system corrected for it. You find in on a RAID 5 system when a DIFFERENT disk fails, and you try to rebuild. The system tries to read the weak sector, and OOPS!" Which is why RAID 5 on aging systems can be problematic. Sophisticated enterprise-class storage from EMC or Hitachi performs "disk-scrubbing" in the back-ground, constantly looking for weak sectors and moving the data. But lower-end systems typically do not have that option. If your controller supports it, make sure it's turned on. Lastly, for the performance geeks out there: RAID 0 - Not redundant at all. Writes data across multiple disks, which gives a very high I/O capability, but does not calculate nor does it write any parity information. Good for very little in the business setting, since downtime will occur eventually. RAID 1 - Mirrors 2 disks. No parity information to calculate, so in general as fast as a single disk, but with redundancy. But doubles the disk costs. Used as higher write performer than RAID 5 / 6. Composite RAID: RAID 1 + 0 or RAID 10 - Mirror multiple pairs of disks to create RGs, then stripe across those RAID 1 RGs to create a RAID 0 super-RG. Redundant due to mirroring of individual pairs, very fast, since there are no parity calculations, and with great potential due to the available I/O bandwidth. Quite safe: A complete failure requires BOTH halves of any one mirrored pair to fail. RAID 0 + 1 - Stripe then mirror. Don't do it. Unlike RAID 10, if you lose just ONE disk in each RAID 0 RG, you're toast. RAID 5 + 0 / 50 - composite multiple RAID 5 RGs then stripe across them. Improved performance over RAID 5. Lastly, for people using RAID, CREATE A HOTSPARE. This is a mechanism for the system to keep one disk aside for emergencies. If a running disk fails, the system will "swap in" the hot spare and begin the rebuild. It reduces the vulnerable time MONITOR THE SYSTEM. It sucks to have the system swap in the hot spare and for you to not know it, Hope that answered your questions.

Squid / DansGuardian on dedicated redundant pair, tho' with Smoothwall on a system as the outer F/W. Honestly, Squid/DG was set up before I started testing Smoothwall. The Smoothwall has been working great, but Squid/DG have worked so well there's been no reason to change the configuration.

Wouldn't the [homes] section do that for you ? Or did you need a second share ? If I needed a second one, I'd do it with an enumerated share, where the name of the folder matches the user name Note that the unsername must match: teachera then needs /something/teachera, /home/teachera, /sambashare/teachera, anything like that. You [userShare] comment = %U Share path = /home/$U read only = No valid users = %U Good luck

I'll try to explain as we go along, maybe you can see if a step was missed. I've been doing this for a long time, so I use the command line. Not sure how the GUI tools do this. 1. Install new hard drive and boot. 2. 2nd hard drive is now /dev/sdb 3. fdisk to partition the drive, probably 1 large partition like /dev/sdb1 4. pvcreate /dev/sdb1. This writes a header page into the partition that says "Hey, I'm a 'physical volume' (part of LVM), and my id is blah-blah." This pv is now available for use 5. vgcreate vgMyVgName /dev/sdb1 (substitute whatever volume group name you wish). This creates a new volume group, and assigned the newky-created partition to it. Now we have a storage pool available. 6. lvcreate --name lvMyLvName --size 10G vgMyVgName. Now we create a logical volume from some of the space in the storage pool called vgMyVgName. 7. mkfs -t ext3 -L SOME_FS_LABEL -c /dev/vgMyVgName/lvMyLvName. We are now writing the file-system metainformation in the logical volume. 8. edit /etc/fstab, add a line: LABEL=SOME_FS_LABEL /mymountpoint ext3 defaults 0 0 depending on what mount point, options and defaults you want 9. mount /mymountpoint. To add another disk partition (say /dev/sdc1) to an existing pool) pvcreate /dev/sdc1 vgextend myVgName /dev/sdc1 To increase the lv size by 10 GB lvextend --size +10G /dev/vgMyVgName/myLvName To grow the ext3 file system to the full size of the newly-expanded volume resize2fs //dev/vgMyVgName/myLvName Hope this helps. See the man pages for more details. good luck.