Re: Question: raid1 behaviour on failure

[Duncan <1i5t5.duncan@cox.net>]

Gareth Pye posted on Thu, 28 Apr 2016 15:24:51 +1000 as excerpted:

> PDF doc info dates it at 23/1/2013, which is the best guess that can
> easily be found.

Well, "easily" is relative, but motivated by your observation I first 
confirmed it, then decided to see what google had to say about the 
authors.

I only looked at the two University of Minnesota authors.  David Lilja is 
a professor there since the 90s, with google turning up various lectures, 
etc, at other universities.  Peng Li, listed as a student in the paper, 
was presumably a graduate student.  His linkedin profile says he's at 
Intel from Aug 2015 to present (software engineer, non-volatitle memory 
device R&D), but was Sr. Engineer, Seagate Tech, Minneapolis/St.Paul 
area, July 2013 to August 2015 (drive arch and performance modeling), and 
was a summer intern at Huawei in San Fran area in the middle of 2012.  
There's several patent and papers to his name.

More importantly for us, however, linkedin links to his personal page, 
still University of Minnesota as he graduated there with a doctorate, PhD 
Advisor, no surprise, Prof. David J Lilja.

http://people.ece.umn.edu/~lipeng/

That page lists as a one project:

Reliability of SATA Port Multiplier (2012).

So while the paper probably came out in January of 2013 as the pdf date 
suggests, he was working on it in 2012.

BTW, his personal site was last updated in June of 2013 and thus doesn't 
mention anything about his move to Intel in 2015.  I'd guess he hasn't 
touched it since getting the doctorate and the job at Seagate, given the 
page mentions that, but the Linkedin profile said it didn't start until 
July of that year, the month after his last personal page at the 
university, update.


Took me longer to write that up than to find it, so it wasn't hard, but 
as I said, "easy" is relative, so YMMV. =:^)

Meanwhile, that was just a single sampling, as the paper itself points 
out, so we don't know where it falls among other port multipliers, or 
even if its behavior was characteristic of that brand and model.

What we do have, however, is that semi-official paper, along with other 
observations here about the reliability, or more accurately, lack of 
reliability, of the various USB2SATA bridge chips, etc.  Even without the 
port multiplier, prior real world posted experience here suggests that 
while single device btrfs on USB via USB2SATA bridge may be reasonable, 
it's not particularly reliable as part of a multi-device btrfs, as too 
often the bridges and devices behind them drop out temporarily due to 
power or other reasons, and btrfs at this point simply doesn't cope well 
with devices dropping out and appearing again, possibly as other 
devices.  With a single-device btrfs there isn't much to screw up, the 
data either gets there or doesn't, and the atomic-cow nature of btrfs 
does at least normally allow for recovery to a known past state plus 
replay of the fsync log between commits if it doesn't, but multi-device 
can quickly get out of hand, particularly if more than one device is 
playing the disappear and reappear game at once.


A reasonable conclusion then, is that the given layout isn't particularly 
reliable at more than one point, making multi-device anything over it 
rather unwise.  JBOD /as/ /JBOD/, creating individual single-device 
filesystems on each device (or device partition), may be somewhat more 
workable, but multi-device, whether at the btrfs level or dm- or md-raid 
level underneath some other filesystem, isn't likely to be very reliable 
at all.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman