waht is jbod?

Joined
Jul 12, 2003
Messages
633
Waht the title says, I got interested in this after seeing a thred in the cool cases forum, I think PS-Rage was doing it up with 1.2 TB in RAID 5. I keep seeing jbod when I look for info on RAID 5, so I'm confused.
 
Just a Bunch Of Disks. It's where you use multiple physical hard drives to create one large logical drive. It's not really RAID, but is similiar to RAID 0 except the drives are spanned instead of stripped, meaning files fill up the first drive completely, then the second, third, etc drives get filled up as each runs out.
 
it's not raid5, jbod is meant for better utilization of disk spaces

similar to raid0, jbod has no data protection
 
Originally posted by ManAngel
it's not raid5, jbod is meant for better utilization of disk spaces

similar to raid0, jbod has no data protection

How do you set up JBOD? Do you need a RAID card?
 
RAID 5 it is for me then. I want some kind of security after blowing out my windows partition because XP wanted to install to the EIDE drive (my backup) instead of the SATA one (where I really wanted XP to install). Rule of thumb, unplug EIDE drives when you install a SATA drive.
 
seems kinda pointless, since I can't see many advantages, and the risks outweigh any possible reward
 
There really is no point for using JBOD anymore with the hard drive sizes we have now, unless you just simply need 1 gigantic drive for some special reason, or bragging rights. If your trying to acheive speed then use RAID 0, for low cost redundancy without fault tolerance use RAID 1, redundency with fault tolerance use RAID 5, redundency with fault tolerance with lots of speed and can withstand a nuclear meltdown use RAID 15/51.
 
I think it's important to remember that not using a raid at all also lies between the data security of raid 1 and raid 0. When you put 2 (or more) disks into a raid 0 array you are exponentially increasing the chance of a drive failure in the array. Whereas a single drive will have less of a chance of failure - it still offers no recourse in the case of failure. This is why raid 5 leans more to the level of reliability of raid 1. When you have a drive failure in raid 5 you can rebuild the array (assuming you blow up only one drive at a time - like a good little boy...)

Raid 5 - in my understanding - falls into usefullness when you need increased speed but are not willing to submit yourself to the risks of raid 0. The more disks you feed to a raid 5 array the more practical it becomes, as the writing of a parity bit will only ever take up the equivalent of 1 physical drive.

So if you can afford 5 100gb disks in your array you will see a noticable speed improvment over raid 1, but still have 400GB of storage.

The penalty for this convenient compromise? The price of a Raid controller that can provide raid 5 functionality...

In storage, as in most all things this attage holds true: FAST, CHEAP, RELIABLE -- PICK 2
 
the reason you keep seeing RAID 5 associated with JBOD is that its common to run software RAID (employing Dyanamic Disks) with a Hardware JBOD), ther is very little to recommend JBOD these days as mentioned

http://www.pcguide.com/ref/hdd/perf/raid/levels/jbod-c.html
If you have some disks in a system that you decide not to configure into a RAID array, what do you do with them? Traditionally, they are left to act as independent drive volumes within the system, and that's how many people in fact use two, three or more drives in a PC. In some applications, however, it is desirable to be able to use all these disks as if they were one single volume. The proper term for this is spanning; the pseudo-cutesy term for it, clearly chosen to contrast against "redundant array of inexpensive disks", is Just A Bunch Of Disks or JBOD. How frightfully clever.

JBOD isn't really RAID at all, but I discuss it here since it is sort of a "third cousin" of RAID... JBOD can be thought of as the opposite of partitioning: while partitioning chops single drives up into smaller logical volumes, JBOD combines drives into larger logical volumes. It provides no fault tolerance, nor does it provide any improvements in performance compared to the independent use of its constituent drives. (In fact, it arguably hurts performance, by making it more difficult to use the underlying drives concurrently, or to optimize different drives for different uses.)

When you look at it, JBOD doesn't really have a lot to recommend it. It still requires a controller card or software driver, which means that almost any system that can do JBOD can also do RAID 0, and RAID 0 has significant performance advantages over JBOD. Neither provide fault tolerance, so that's a wash. There are only two possible advantages of JBOD over RAID 0:

Avoiding Drive Waste: If you have a number of odd-sized drives, JBOD will let you combine them into a single unit without loss of any capacity; a 10 GB drive and 30 GB would combine to make a 40 GB JBOD volume but only a 20 GB RAID 0 array. This may be an issue for those expanding an existing system, though with drives so cheap these days it's a relatively small advantage.

Easier Disaster Recovery: If a disk in a RAID 0 volume dies, the data on every disk in the array is essentially destroyed because all the files are striped; if a drive in a JBOD set dies then it may be easier to recover the files on the other drives (but then again, it might not, depending on how the operating system manages the disks.) Considering that you should be doing regular backups regardless, and that even under JBOD recovery can be difficult, this too is a minor advantage.
!

http://sunsite.uakom.sk/sunworldonline/swol-08-1999/swol-08-raid3.html

JBOD
"One way to create a large storage subsystem is to not use RAID at all. Such systems often go by the moniker of "just a bunch of disks," or JBOD.

JBOD is the way we used to do things back in the olden days, when normal systems maintenance included loading coal into the machine hopper and adjusting the processor drive belts. To create a JBOD storage subsystem, you take a bunch of disks and attach them to your system, usually via one or more SCSI controllers. Individual drives may have some smarts, including an on-drive cache, but there is little other hardware support for your storage subsystem.

Drive management in a JBOD environment occurs at the system level. You use conventional tools to format, partition, and mount the physical drives. Users then take advantage of the file systems you've mounted. For any sort of realistic performance management, users, especially database administrators, will need to know exactly where every file system is created and mounted, so that they don't create applications that saturate one drive or SCSI controller.

For large installations, JBOD is simply not an option. If you work in a small shop on a shoestring budget, however, JBOD can help meet some of your disk storage needs. In these cases, you'll be relying on your applications and databases to provide redundancy and recovery tools, along with robust backups to help you through serious drive failures.

The one advantage of a JBOD installation is that it forces you to become intimately familiar with your drives, controllers, and disk performance. Once you have fully grasped the inner workings of disk storage, a later transition to a more sophisticated RAID subsystem will be much easier, since you will understand how to balance loads across mmultiple controllers, detect disk hot spots, and recognize application usage patterns among your disk drives. In addition, a JBOD architecture is the basis on which software RAID solutions are constructed. Learning how to make JBOD work effectively will help you make a software-based RAID configuration work better as well. "

Dynamic Disks (Software RAID & Spanned Volume)
Description of Disk Groups in Windows Disk Management
Dynamic vs. Basic Storage in Windows 2000
Basic and Dynamic Disks @ Windows & .net Magazine
HOW TO: Recover an Accidentally Deleted NTFS or FAT32 Dynamic Volume
Dynamic Disk Hardware Limitations (No firewire, USB, removable or laptop)
HOW TO: Set Up Fault-Tolerant Sets on Dynamic Disks in Windows 2000
Dynamic Disk Numbering and the DmDiag.exe Tool
HOW TO: Regenerate a Dynamic Mirrored Volume in Windows 2000
Restrictions on Extending or Spanning Simple Volumes on Dynamic Disks

Limits of Dynamic Disks in Windows 2000
LDMDump (Freeware utility) @ sysinternals
LDM Database @ Linux-NTFS project
LDM FAQ @ Linux-NTFS project
 
Originally posted by xonik
Just a small correction: RAID 5 is not a redundant RAID level by definition,

??? isnt either dedicated or distributed parity considered redundant?

3 or 5
 
I tend to go by the dictionary's definition of redundant, which states:

http://dictionary.reference.com/search?q=redundancy

re·dun·dan·cy

[...]

6. Electronics. Duplication or repetition of elements in electronic equipment to provide alternative functional channels in case of failure.

Basically, I see it as such: If the data of an array is likened to an essay, parity "fills in the blanks" (after a drive failure), while redundancy has "an extra copy" just in case you drop the essay in a puddle on the way to school ;)
 
I define redundancy as something which saves my butt when my essay starts making a funny clicking noise after my last power-outage...
 
Originally posted by dewhite
I define redundancy as something which saves my butt when my essay starts making a funny clicking noise after my last power-outage...

I would tend to agree
I mean it is Redundant Array or Independent\Inexpensive Disks

I would say that applies to the disks, not the level, any disk that can be replaced and rebuilt quailifies, the fact that parity instead of a direct mirror is employed being unimportant to the "traditional" definition

since RAID 0 is actually AID
by removing both 3 & 5 from the definition of RAID that leaves only mirrors RAID 1
(RAID 2 & 4 being more or less obsolete, even then 4 employs parity)

discounting all nested arrays, since there is both 1+0 3+0 5+0
 
Back
Top