Recording stops "Your machine can't keep up"

[sunrat]

You have /home LVM across 3 separate disks, and /var on one of the same disks. I think sharing a disk with /var is a bad idea as system logs are written there.
Personally I'd ditch the LVM completely, have /home and/var on the first disk (not separate partitions but included under / ) and SWAP, with the second disk as something like /sessions dedicated to recording and the third one for long-term storage like /storage. Essentially the same as PBuryk suggested. It's pretty much what I do and I've never had disk i/o problems on this system.
I did have a similar "machine can't keep up" message trying to record on a laptop with only the system disk. Even that worked much better recording to an external USB3 disk.

[madmaxmiller]

You have /home LVM across 3 separate disks, and /var on one of the same disks. I think sharing a disk with /var is a bad idea as system logs are written there.
Personally I'd ditch the LVM completely, have /home and/var on the first disk (not separate partitions but included under / ) and SWAP, with the second disk as something like /sessions dedicated to recording and the third one for long-term storage like /storage. Essentially the same as PBuryk suggested. It's pretty much what I do and I've never had disk i/o problems on this system.
I did have a similar "machine can't keep up" message trying to record on a laptop with only the system disk. Even that worked much better recording to an external USB3 disk.

I second that.
In my particular setup I have / on one disk, /home/LOCALDATA on the second, for the sessions, and /home/RESOURCES on number three, for sample libraries etc. For bulk storage I have my NAS in a rack outside on NFS mounted under /home/DATA.

MMM
P.S. ...and swap, /var/log and /tmp have their own partitions, just in case one gets flooded due to error, so / doesn't get swamped in that case

[sunrat]

P.S. ...and swap, /var/log and /tmp have their own partitions, just in case one gets flooded due to error, so / doesn't get swamped in that case

Definitely have a swap partition. I don't bother with the other 2 - i had /var/log/ swamp my filesystem once in 18 years or so of Linux use and even that was many years ago and was on Debian unstable. I dare say Ubuntu would be more susceptible to that than Debian Stable so your caution may be justified.
/tmp is usually mounted in RAM by default these days so not necessary to put it on HD. You can check with

Code:

$ df /tmp

If it says "tmpfs" it's mounted in RAM.

Code:

$ df /tmp
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs            2014540    28   2014512   1% /tmp

[PBuryk]

Regarding /tmp (tmpfs) being part of RAM:

Linux admins found out long ago that if users (or their apps) used /tmp as a scratchpad
area, and left all their "bird droppings" hanging around there, that they would eventually
experience performance issues (or even hangs or crashes) because the system would:
1) need to swap more than normal or
2) hang up or crash
due to the lack of available RAM or available space in /tmp.
(eg., trying to render a really big vid file or song file in /tmp when you only have 4-8 GB RAM!)

Servers should never use tmpfs; should always config /tmp as its own partition.

DAWs, most likely being used in a more "personal" sense, should operate just fine by
having /tmp as a normal directory under / . Allocating a generous amount of disk space
to the "system" (255 GB in this case) should be way more than what is needed for a
stable OS performance as long as any other heavy users of filesystem space are
setup as their own partition(s). Given the capacity of HDD & SSD drives today,
specifying one partition for the entire OS install should work just fine. Use
additional drives for DAW projects and long term storage/backups.

Please note: the above recommendations are for laptop base setups.
For desktop or other workstation form factors that can accommodate multiple disks
I would recommend the following:

1) One disk for SWAP, /tmp, /var & /Archives- - - Configure as (4) partitions.
If /var/tmp is a defined area in your OS's filesystem, link it to /tmp.
Mount /var and /tmp on / at system boot-up time.
/Archives is for long term storage/backups.
Mount this filesystem on / at boot time or whenever you need to.

2) One disk for the rest of the OS build.

3) One disk for your DAW projects.
You can mount this filesystem anywhere you desire - /DAW, /Projects, /Studio - whatever.
I'm the only user of my DAW so I have mine mounted as /home/Studio.
If there were other users using my DAW I would mount it as /Studio.
You can also specify that this be mounted at boot time or,
if your system is a multi-purpose build, mount it only when you want to work music related projects.
In the case of the latter you might also want a disk for whateverelse you're using your computer for.

Comments and suggestions for improvement are always welcome.

Cheers!

Patrick

[sunrat]

/tmp is mounted in RAM by default in a fresh Debian installation which is why I mentioned it, and I never change it and never have a problem with it. I also put all of my system in one partition and never (lately) have a problem with that. You can split it up as much as you like, it's your system, and configurations of separate /var, /tmp are advised for servers.
The bottom line is use a drive separate from your system drive for recording.

[Dingo]

100% with sunrat..."use a drive separate from your system drive for recording."

[guysherman]

Hi All,

Thanks for the input.

I've done some further tests, specifically I set my system up to record from spotify into Ardour, and Mixbus. In both cases I was able to record two tracks from spotify, for over 12 hours (at which point I stopped the tests). So I don't think it is actually a disk performance issue. I suspect the issue is more likely a CPU speed issue.

However, does anyone know if the performance of LVM degrades when there is high CPU load? It strikes me that between VCV rack, and all the extra DSP that mixbus does when monitoring, that there isn't enough CPU headroom to navigate the LVM side of things.

Thoughts on this? Naturally, re-organising my disks will be a giant pain in the backside, so I'm definitely trying to avoid that.

Cheers,

Guy.

[ErwinB]

...

Thoughts on this? Naturally, re-organising my disks will be a giant pain in the backside, so I'm definitely trying to avoid that.

Cheers,

Guy.

You can move logical volumes to the different physical volumes using the pvmove utillity that is part of the lvm commands. (see the manual pages for use) This would make it possible to move the different home parts to one disk if you play it right and stll have enough free extends on the destination disks. but it would allow for the reorganisation of the disks with less pain.

[madmaxmiller]

I've done some further tests, specifically I set my system up to record from spotify into Ardour, and Mixbus. In both cases I was able to record two tracks from spotify, for over 12 hours (at which point I stopped the tests). So I don't think it is actually a disk performance issue. I suspect the issue is more likely a CPU speed issue.

Which gets us back to my first question: are you using a virtual modular on the same machine you are recording on? What does (h)top say?
Recording a stereo stream from somewhere can be done with a 20 years old Celeron.

MMM

[guysherman]

I've done some further tests, specifically I set my system up to record from spotify into Ardour, and Mixbus. In both cases I was able to record two tracks from spotify, for over 12 hours (at which point I stopped the tests). So I don't think it is actually a disk performance issue. I suspect the issue is more likely a CPU speed issue.

Which gets us back to my first question: are you using a virtual modular on the same machine you are recording on? What does (h)top say?
Recording a stereo stream from somewhere can be done with a 20 years old Celeron.

MMM

Yep, it is all on one machine, because that's the only computer I have Will have to take a look at the cpu usage in more detail.