Should We Ever Talk About JBODs
-
Now that we have concluded that the term or acronym "JBOD" should not be used in any circumstance, we need to document what should be used instead. We can't leave everyone who comes across this hanging...
I would think it depends on the situation and context.
Some starters:
-
If you are talking about configuring internal server storage
-
If you are referring to a multi-hard disk enclosure such as DAS (even that term can be misleading... a DAS could be a cdrom... but that's another discussion I gather)
-
SAM, you see more on forums than I do... you have a list of cases JBOD is used to add?
-
-
Very interesting conversation! I never really thought about the various ways the term could be used.
I have always used JBOD to describe a bunch of disks in an expansion storage cabinet that did not have a hardware based RAID controller built-in.
You could access the drives independently or use software RAID for some, if not all, of them. The logic of controlling them would be external to the cabinet itself, therefore it's a collection of "just a bunch of disks."
Steve
-
@scottalanmiller said in Should We Ever Talk About JBODs:
JBOD is an abbreviation for "Just a Bunch Of Disks" and is meant to refer to, well, no one is exactly sure when to use it properly. People often use it to mean "not RAID" or not "hardware RAID" or "not yet RAIDed" but they forget that spanning, RAIN or whatever would make something no longer a JBOD. And some people mean it only to refer to hardware, but RAID is software, as is RAIN. Everything is JBOD at some point and basically nothing is by the time that it is in use.
I'm not clear when we can ever usefully use the term where it doesn't prompt a long and confusing explanation to clear up what is actually intended. I have a feeling that this is a term that simply should not exist as there is just no time that using it is useful.
Does anyone have any idea of a time when it would actually be important to have this term and, if so, how would we use it without further explanation?
Storage pools on Windows Server. You can add disks as needed, and over allocate with thin provisioning. I consider that a straight up JBOD because of over allocation and adding disks as needed. Not much to it other than grabbing disks out of primordial and assigning to a VHD. Also consider it JBOD because though you can choose parity, it is not inherent.
-
@BBigford said in Should We Ever Talk About JBODs:
Storage pools on Windows Server. You can add disks as needed, and over allocate with thin provisioning. I consider that a straight up JBOD because of over allocation and adding disks as needed. Not much to it other than grabbing disks out of primordial and assigning to a VHD. Also consider it JBOD because though you can choose parity, it is not inherent.
But in that case again, doesn't just calling it "disks" cover that? A Storage Pool is "post JBOD" at best. Once in a pool, by definition it can't be JBOD any longer.
-
@scottalanmiller said in Should We Ever Talk About JBODs:
@BBigford said in Should We Ever Talk About JBODs:
Storage pools on Windows Server. You can add disks as needed, and over allocate with thin provisioning. I consider that a straight up JBOD because of over allocation and adding disks as needed. Not much to it other than grabbing disks out of primordial and assigning to a VHD. Also consider it JBOD because though you can choose parity, it is not inherent.
But in that case again, doesn't just calling it "disks" cover that? A Storage Pool is "post JBOD" at best. Once in a pool, by definition it can't be JBOD any longer.
Definitely post-JBOD (and I am definitely going off the path and stretching the term). But once in a pool, they are literally just a bunch of disks. They are not in a RAID configuration, so that right there opens up the idea that they could be a JBOD. Since a JBOD can expose the drives individually, or as one logical volume, a pool could be called a JBOD depending on how the pool is configured.
Since the pool can consist of any drives, can be setup as one volume, can be over-allocated, and drives dynamically added to it, I would definitely say it could be called a JBOD (at least as far as Storage Pools goes for Windows Server). Literally just a bunch of disks thrown into a pool. There are some nitty gritty I suppose about what makes a JBOD an actual JBOD, but down to the basics of it, I think the criteria is met with Storage Pools (just my opinion though).
-
@BBigford said in Should We Ever Talk About JBODs:
@scottalanmiller said in Should We Ever Talk About JBODs:
@BBigford said in Should We Ever Talk About JBODs:
Storage pools on Windows Server. You can add disks as needed, and over allocate with thin provisioning. I consider that a straight up JBOD because of over allocation and adding disks as needed. Not much to it other than grabbing disks out of primordial and assigning to a VHD. Also consider it JBOD because though you can choose parity, it is not inherent.
But in that case again, doesn't just calling it "disks" cover that? A Storage Pool is "post JBOD" at best. Once in a pool, by definition it can't be JBOD any longer.
Definitely post-JBOD (and I am definitely going off the path and stretching the term). But once in a pool, they are literally just a bunch of disks. They are not in a RAID configuration, so that right there opens up the idea that they could be a JBOD. Since a JBOD can expose the drives individually, or as one logical volume, a pool could be called a JBOD depending on how the pool is configured.
Since the pool can consist of any drives, can be setup as one volume, can be over-allocated, and drives dynamically added to it, I would definitely say it could be called a JBOD (at least as far as Storage Pools goes for Windows Server). Literally just a bunch of disks thrown into a pool. There are some nitty gritty I suppose about what makes a JBOD an actual JBOD, but down to the basics of it, I think the criteria is met with Storage Pools (just my opinion though).
If JBOD only means non-RAID, then RAIN is JBOD, which makes no sense. Would you consider AetherStore, Exablox, Scale, VSAN, Gluster, CEPH and such to be JBOD? They are anything but "just a bunch of disks", they are single storage systems. Once the term "pool" exists, I think JBOD has to be ruled out.
-
@BBigford said in Should We Ever Talk About JBODs:
Since the pool can consist of any drives, can be setup as one volume, can be over-allocated, and drives dynamically added to it, I would definitely say it could be called a JBOD ...
That description to me sounds like you are about to say that since they can be all those things then they clearly can't be a JBOD, but you end with the opposite conclusion than I would expect from the description.
-
@BBigford said in Should We Ever Talk About JBODs:
Literally just a bunch of disks thrown into a pool.
Same as "just a bunch of disks thrown into an array".
Normally that's the polar opposite of JBOD.
-
Here's wikipedia's def:
So going by that, it's a JBOD until you span them (or essentially do anything else with multiple disks). So then theoretically, I guess if you had a specific mount point for each drive, it would be a JBOD.
sda -> /disk1
sdb -> /disk2
sdc -> /disk3So I guess if nothing is spanned across, it could be a JBOD?
-
@stacksofplates said in Should We Ever Talk About JBODs:
Here's wikipedia's def:
So going by that, it's a JBOD until you span them (or essentially do anything else with multiple disks). So then theoretically, I guess if you had a specific mount point for each drive, it would be a JBOD.
sda -> /disk1
sdb -> /disk2
sdc -> /disk3So I guess if nothing is spanned across, it could be a JBOD?
It doesn't list only the two things, or else RAID would still be JBOD. It just is two examples there. One example is JBOD, one is SPAN. There are many others, some listed, some not. Wasn't MAID on the list, too?
-
Isn't a pool a form of spanning? Do pools display the original devices through, or new ones? Pools are an LVM, and any LVM use means JBOD is long gone.
-
@scottalanmiller said in Should We Ever Talk About JBODs:
re. One example is JBOD, one is SPAN. There are many others, some listed, some not. Wasn't MAID on the list, too?
I only copied some of the definition. My point was they said a SPAN is "from" a JBOD. Being from, it can't be that after you span them.
-
@scottalanmiller said in Should We Ever Talk About JBODs:
Isn't a pool a form of spanning? Do pools display the original devices through, or new ones? Pools are an LVM, and any LVM use means JBOD is long gone.
I never mentioned pooling. I wasn't talking about any logical volume implementations. Just straight disks with file systems mounted to individual mount points.
-
@scottalanmiller said in Should We Ever Talk About JBODs:
@stacksofplates said in Should We Ever Talk About JBODs:
Here's wikipedia's def:
So going by that, it's a JBOD until you span them (or essentially do anything else with multiple disks). So then theoretically, I guess if you had a specific mount point for each drive, it would be a JBOD.
sda -> /disk1
sdb -> /disk2
sdc -> /disk3So I guess if nothing is spanned across, it could be a JBOD?
It doesn't list only the two things, or else RAID would still be JBOD. It just is two examples there. One example is JBOD, one is SPAN. There are many others, some listed, some not. Wasn't MAID on the list, too?
Yeah, MAID was on the list. I only copied the first two because of the "from JBOD" phrase.
-
@stacksofplates said in Should We Ever Talk About JBODs:
@scottalanmiller said in Should We Ever Talk About JBODs:
re. One example is JBOD, one is SPAN. There are many others, some listed, some not. Wasn't MAID on the list, too?
I only copied some of the definition. My point was they said a SPAN is "from" a JBOD. Being from, it can't be that after you span them.
Ah, just like a pool is "from a JBOD."
-
Uh-oh. Dell is doing it now ^_^
-
Argh
-
