Talk:Non-RAID drive architectures

This is the talk page for discussing improvements to the Non-RAID drive architectures article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Computer hardware task force (assessed as Low-importance).

Software: Computing Low‑importance

	This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

JBOD and SPAN[edit]

Moved from Talk:Standard RAID levels —Nils von Barth (nbarth) (talk) 00:53, 28 September 2009 (UTC)[reply]

Some tells that JBOD and SPAN is the same. Other says that JBOD is not RAID. JBOD will every disk have a volume and SPAN will all disks be like one big disk. 80.203.188.154 15:43, 8 February 2007 (UTC)[reply]

Agreed. I have not come across any vendor of SAN attached RAID controller that provides spanning and calls it JBOD. If you create a JBOD from a physical disk, it will be presented as a single logical disk that corresponds directly with ONE physical disk. I first heard the term JBOD in IBM in 1995 and it was used to mean a single disk that was not being managed by the RAID controller. Can anyone provide examples of vendors that are allowing spanning / concatenation and call it JBOD - I know of none. I think a clarificaiton that JBOD was originally used to mean a single physical disk that is presenting a single logical disk that corresponds 1:1 LBA wise. Baz whyte 20:19, 26 February 2007 (UTC)[reply]

Moreover, we have this clause:

Many Linux distributions use the terms incorrectly and refer to JBOD as "linear mode" or "append mode".

Is there any proof that it's incorrect usage of term? I tend to think that basically, there are no well-understood term for that thing. JBOD, Spanning, concatenation, linear and appending can all mean the same thing or different things, depending on who uses it. May be we shoudl reflect that such a mess exists, instead of trying to confuse our reader? --GreyCat 05:08, 6 September 2007 (UTC)[reply]

I've never seen this usage of JBOD before. JBOD is the *absence* of RAID of any form, you are just getting direct access to a bunch of disks. Vendors like Adaptec's, Sun's and SuperMicro's usage of the term matches this. It seems to me the notion that JBOD is concatenated RAID-0 is a misunderstanding who has spread out from ordinary PC users. I'd also like to express my skeptisism about calling "linear mode" incorrect. It may be unusual terminology, but I don't see what's wrong with it. FWIW, Solaris Volume Manager avoids the issue and doesn't use the RAID word for "concatentations" and "stripes". Kjetilho 13:31, 12 November 2007 (UTC)[reply]

I am no expert, but I believe the concatenation referred to here, which is used to create a single logical disk out of multiple physical disks is more commonly called "BIG". I assume this is because it is just one big drive and there needs to be a way to distinguish it from "JBOD". Whereas "JBOD" is literally "Just a Bunch Of Disks", a interface approach which causes the physical drives to appear as a bunch of different disks. I have been looking to purchase a dual bay SATA enclosure and this appears to be most common terminology used, with some controllers supporting both modes. Clarifying these two non-RAID operational modes on the wiki would be great. Ritecite (talk) 06:06, 22 June 2008 (UTC)[reply]

I vote for JBOD as one baseline framework for RAID creation. Note, JBOD is a HW device for a bunch of disks or drives. It has different form factor and dozens of disk drives in the enclosure like 2U25 or 3U15 JBOD. However, RAID is the term for data storage technology which can be applicable on multi drives cases. So JBOD is one regular platform to implement RAID function based on HW and/or SW support. That's it. So I strongly suggest to add JBOD term back here or create a single page for JBOD. Thanks:-)

In other words, JBOD is a physical device but RAID is logical and a abstract for multi-disks.

--SamSong2008 (talk) 02:25, 2 February 2009 (UTC)[reply]

Thanks all for the comments!

I’ve moved JBOD (and others) to this new page; I agree that etymologically and narrowly speaking (as used by manufacturers), JBOD means independent drives. As noted, JBOD is used by some to refer to drive spanning/concatenation, so I’ve added a usage note to that effect, but emphasized that this is an ambiguous use, and that SPAN or BIG is less ambiguous. I’ve also added references showing both usages.

Hope the resulting page satisfactorily describes matters; else please change, of course.

—Nils von Barth (nbarth) (talk) 01:25, 28 September 2009 (UTC)[reply]

At SPAN 'Implementations' it is mentioned that single drive failure leaves other drives unreadable in OSX. This is not mentioned for Linux LVM, which confuses the reader into thinking in LVM the leftover disks are still readable. I think this is also false, though. But not entirely sure. Redsandro (talk) 13:02, 30 October 2010 (UTC)[reply]

After doing some research, the terms "BIG" and "SPAN" are almost never used with regard to a non-RAID drive configuration. I'm having a very hard time believing that these terms act actually true and not something that someone invented. Having a degree in Computer Science and as a person semi-knowledgeable of the subject, I'm disputing the validity of these points because there are zero cited sources with this information. It is false and should be removed immediately. Jrdoane (talk) 8:48, 18, December 2012 (UTC)

Merge discussion[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was not to merge. – voidxor ^{(talk | contrib)} 01:44, 3 February 2015 (UTC)[reply]

I propose that Non-RAID drive architectures be merged into RAID in the Non-RAID drive architectures section. The standalone article is mostly uncited and somewhat redundant. While a little longer than a stub, it's too short (especially once uncited material is removed) to justify an independent article for which readers of RAID must switch pages to see basic details. – voidxor ^{(talk | contrib)} 05:39, 11 February 2013 (UTC)[reply]

Weak disagree: In theory they may be best separate as RAID is a specific type of storage. While I would lean towards merge on article size, this article isn't too small, it just needs some more references. Widefox; talk 14:06, 6 March 2013 (UTC)[reply]
Disagree: It should be better to have a separate article, for improved readability. Also, with the latest edits, this article became more readable with better explanations, and more references were added. I'd support the merge only in case "Concatenation (SPAN, BIG)" section becomes deleted due to factual accuracy. On the other hand, we have a very short Spanned volume article, which should probably be merged into this article, as in fact it's a JBOD configuration. — Dsimic (talk) 22:27, 30 December 2013 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.