1 |
On Thu, Dec 23, 2021 at 10:27 AM Rich Freeman <rich0@g.o> wrote: |
2 |
> |
3 |
> On Thu, Dec 23, 2021 at 11:56 AM Mark Knecht <markknecht@×××××.com> wrote: |
4 |
> > |
5 |
<SNIP> |
6 |
> |
7 |
> > Instead |
8 |
> > of a ZIL in machine 1 the SSD becomes a ZLOG cache most likely holding |
9 |
> > a cached copy of the currently active astrophotography projects. |
10 |
> |
11 |
> I think you're talking about L2ARC. I don't think "ZLOG" is a thing, |
12 |
> and a log device in ZFS is just another name for ZIL (since that's |
13 |
> what it is - a high performance data journal). |
14 |
> |
15 |
|
16 |
Thank you. Yes, L2ARC. |
17 |
|
18 |
> L2ARC drives don't need to be mirrored and their failure is harmless. |
19 |
> They generally only improve things, but of course they do nothing to |
20 |
> improve write performance - just read performance. |
21 |
> |
22 |
> > As always I'm interested in your comments about what works or |
23 |
> > doesn't work about this sort of setup. |
24 |
> |
25 |
> Ultimately it all comes down to your requirements and how you use |
26 |
> stuff. What is the impact to you if you lose this real-time audio |
27 |
> recording? If you will just have to record something over again but |
28 |
> that isn't a big deal, then what you're doing sounds fine to me. |
29 |
|
30 |
Actually, no. |
31 |
|
32 |
> If |
33 |
> you are recording stuff that is mission-critical and can't be repeated |
34 |
> and you're going to lose a lot of money or reputation if you lose a |
35 |
> recording, then I'd have that recording machine be pretty reliable |
36 |
> which means redundant everything (server grade hardware with fault |
37 |
> tolerance and RAID/etc, or split the recording onto two redundant sets |
38 |
> of cheap consumer hardware). |
39 |
|
40 |
Closer to mission critical. |
41 |
|
42 |
When recording live music, most especially in situations with |
43 |
lots of musicians, you don't want to miss a good take. In cases where |
44 |
you are just capturing a band playing it's just about getting it on disk, |
45 |
however in cases where you are adding to music that's already on disk, |
46 |
say a vocalist singing live over the top of music the band played earlier |
47 |
then having the hardware screw up a good take is really a downer. |
48 |
|
49 |
> |
50 |
> I do something similar - all the storage I care about is on |
51 |
> Linux/ZFS/lizardfs with redundancy and backup. I do process |
52 |
> photos/video on a windows box on an NVMe, but that is almost never the |
53 |
> only copy of my data. I might offload media to the windows box from |
54 |
> my camera, but if I lose that then I still have the camera. I might |
55 |
> do some processing on windows like generating thumbnails/etc on NVMe |
56 |
> before I move it to network storage. In the end though it goes to zfs |
57 |
> on linux and gets backed up and so on. If I need to process some |
58 |
> videos I might copy data back to a windows NVMe for more performance |
59 |
> if I don't want to directly spool stuff off the network, but my risks |
60 |
> are pretty minimal if that goes down at any point. And this is just |
61 |
> personal stuff - I care about it and don't want to lose it, but it |
62 |
> isn't going to damage my career if I lose it. If I were dealing with |
63 |
> data professionally it still wouldn't be a bad arrangement but I might |
64 |
> invest in a few things differently. |
65 |
> |
66 |
|
67 |
In the case of recording audio it just gets down to how large a |
68 |
project you are working on. 3 minute pop songs aren't much of an |
69 |
issue. 10-20 stereo tracks at 96KHz isn't all that large. For those |
70 |
the audio might fit in DRAM. However if you're working on some |
71 |
wonderful 30 minute prog rock piece with 100 or more stereo tracks |
72 |
it can get a lot larger but (in my mind anyway) the main desktop |
73 |
machine will have some sort of M.2 and maybe it fits in there |
74 |
and it gets read off hard disk before the session starts and there's |
75 |
probably no problem. |
76 |
|
77 |
I haven't given this a huge amount of worry because my current |
78 |
machine does an almost perfect job with 8-9 year old technology. |
79 |
|
80 |
In the case of astrophotography I will have multiple copies of the |
81 |
original photos. The process of stacking the individual photos can |
82 |
create gigabytes of intermediate files but as long as the originals |
83 |
are safe then it's just a matter of starting over. In my astrophotography |
84 |
setup I create about 50Mbyte per minute and take pictures for hours |
85 |
so a set of photos coming in at 1-2GB and up to maybe 10GB isn't |
86 |
uncommon. I might create 30-50GB of intermediate files which |
87 |
eventually get deleted but they can reside on the server while I'm |
88 |
working. None of that has to be terribly fast. |
89 |
|
90 |
> Just ask yourself what hardware needs to fail for you to lose |
91 |
> something you care about at any moment of time. If you can tolerate |
92 |
> the loss of just about any individual piece of hardware that's a |
93 |
> pretty good first step for just about anything, and is really all you |
94 |
> need for most consumer stuff. Backups are fine as long as they're |
95 |
> recent enough and you don't mind redoing work. |
96 |
> |
97 |
Agreed. |
98 |
|
99 |
Thanks, |
100 |
Mark |