TSP1989: War Requiem

War Requiem. Derek Jarman. 1989.

There should have been subtitles on the DVD.  I was straining to understand what they were singing, and sometimes I wouldn’t understand what they were singing at all.  So I went on teh interwebs, and some parts of the libretto were in Latin, not English.  Har de har.

Anyway, the music was so great that I bought the CD box set right now.

This post is part of The Tilda Swinton Project.

Further Adventures in Storage

DSC01703In the last installment in this series, I had made a 4x 8TB eSATA RAID5 set, and performance was slow, and it was unstable.

The disks went AWOL all the time with messages like

 

May 14 20:52:25 big-tex kernel: [ 3189.112594] ata5.03: hard resetting link
 ...
May 14 20:53:32 big-tex kernel: [ 3255.728753] ata5.03: detaching (SCSI 4:3:0:0)

Things that could be causing this: 1) a bad disk enclosure. 2) a bad eSATA cable. 3) Bad port multiplier support in the chipset. 3) the disks. f) other.

So I switched out the easiest thing: I went from eSATA to USB3.

And it’s been rock stable since then.  Dirt slow, but rock stable.  Which is fitting.

How slow?

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  1      0  33320 1023516 2059076    0    0     0 42835 4476 7875  0 24 43 33
 0  1      0  34432 1023596 2105640    0    0     0 40993 4341 7661  0 23 43 34
 0  1      0  29632 1023684 2143344    0    0     1 39959 4268 7486  0 22 43 34

40MB/s write speed slow.  That’s so slow that when I rip blu-ray disks, makemkv complains about the disk being too slow — it’s reading the disk faster than it can write to disk.

That’s depressing.

But Linux 4.1 was released today, and it’s supposed to have improved (i.e. faster) RAID5 support.  I wasn’t holding my breath, but look:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 2  1      0  30276  47320 3320332    0    0   123 47421 3952 6765  0 23 42 35
 1  1      0  32604  47436 3300164    0    0     2 55326 4444 7456  0 28 39 33
 0  1      0  29380  47564 3290044    0    0     2 53297 4302 7218  0 27 39 34
 0  1      0  28660  47696 3276640    0    0     2 55374 4434 7387  0 28 39 34
 0  1      0  28712  47840 3262992    0    0     8 56602 4460 7496  0 28 38 33
 0  1      0  29992  47948 3252800    0    0     2 52579 4254 7102  0 26 39 35

It’s faster!  It went from 40MB/s to 53MB/s.  So it was somewhat CPU constrained?  (It’s a dual core 1GHz AMD G-T40E processor…)

It’s still really slow, but perhaps that’s fast enough for makemkv…

What about with -o data=writeback?

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  2      0  31292  47952 3242020    0    0     2 58233 4377 7189  0 29 19 52
 0  2      0  31144  48072 3231984    0    0     2 58205 4379 7118  0 29 18 52
 0  2      0  28600  48184 3224956    0    0     2 57498 4282 6964  0 29 20 51
 0  2      0  32928  48312 3210744    0    0     2 60983 4474 7302  0 32 19 50
 1  1      0  30068  48460 3208108    0    0    15 62961 4593 7472  0 33 18 48

So about 58MB/s.  Whee!  The naughts called and wants their write speed back!

By the way, I connected my previous RAID box to the same machine with eSATA just to check whether the port multiplier stuff was unstable.  And that’s been stable for weeks.  So it is, as usual, certain combinations of certain gadgets via certain technology that’s the problem…