Is there a bug report for this?
This is likely a false positive and something specific to your system.
Even an old slow USB2 disk is sufficiently fast to read a few hundred mono tracks (40 [MByte / sec] / 4 [bytes/sample/track] / 48000 [sample/sec] = 218 mono tracks).
Seeking can cause issues, but that is on the order of 10ms, and with a 10 second audio buffer it is negligible (besides the Linux kernel also buffers data from disk).
I think it may be an erroneous message, but I also have had crashes after this appeared several times.
I’m downloading the Lenovo diagnostics package for Linux and will run this asap to see if that shows any hardware issues
I have made a bug report: 0009517: crashes when trying to edit.
There’s a file called dragcrash.txt I uploaded on 8th November in there.
@Paul said there is a known bug but that no one has been able to find a reliable recipe to replicate it
I’m gonna run the Lenovo diagnostic tests now and see if anything shows up - hopefully not though!
Hi,
There is no ‘partitioning’ in AV Linux itself, you have complete control over that with the MX installer and whatever partitioning scheme you like… In the User Manual I do suggest keeping AV Linux contained to it’s own partition and using the home folder for temporary storage and putting media data on separate drives and partitions where it is safe in the event you need to do an emergency reinstall, also if you want to try and install another OS then your data is all safe and ready to be accessed and you can hit the ground running.
There is something seemingly amiss with your SSD, even many years ago installing Linux and doing work with Ardour on older machines with single 7200rpm SATA HDD’s I never saw issues with the disk speed errors, an SSD even with everything all on one drive should be exponentially fast enough to run many many tracks on Ardour, indeed the bottlenecks of CPU and RAM would likely rear their heads before track counts and disk speed became an issue with an SSD.
Many thanks GMaq. I think that my problem may be due to the RAID system on the computer not being employed properly
I have looked up some commands to check it and the results seem to indicate that whislt there is a RAID, the drives themselves are not part if it:
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices:
mel@mx:~
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 476.9G 0 disk
|-sda1 8:1 0 256M 0 part /boot/efi
|-sda2 8:2 0 468.7G 0 part /
-sda3 8:3 0 8G 0 part [SWAP] sdb 8:16 0 931.5G 0 disk |-sdb1 8:17 0 16M 0 part -sdb2 8:18 0 931.5G 0 part /home/mel/data
Not really sure how to proceed now
Hi Robin
Am I right thinking that the results below show my drives are not being used by the RAID in the thinkstation?
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: [none]
mel@mx:~
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 476.9G 0 disk
|-sda1 8:1 0 256M 0 part /boot/efi
|-sda2 8:2 0 468.7G 0 part /
`-sda3 8:3 0 8G 0 part [SWAP]
sdb 8:16 0 931.5G 0 disk
|-sdb1 8:17 0 16M 0 part
`-sdb2 8:18 0 931.5G 0 part /home/mel/data
mel@mx:~
$
Maybe this is the cause of the problem?
I’ve found theres no mdadm file so I guess the RAID cannot be functioning.
Would this slow down the disk read/write functions?
The BIOS says SATA is is in AHCI mode so I guess that was a red herring
Seems unlikely to be the problem with ~360GB free of a ~460GB drive. Maybe if the drive was previously close to full and a lot of files were moved off to other storage, but not if the drive really has 360GB which have never been used.
With HDD, but “seeking” isn’t really a thing with SSD. ( I know Robin knows this, just pointing it out for OP).
RAID system? Your earlier message stated that your computer had “an SSD.” How many SSD’s do you have? I only see /dev/sda listed, if you had multiple drives they should show up as /dev/sda, /dev/sdb, /dev/sdc, etc.
Oh, I see you have a later post which shows /dev/sdb.
It appears to be a different size than /dev/sda, so RAID0 or RAID1 striping would no really make sense in that case.
Is /dev/sdb a second SSD? Does the mount name of /home/mel/data imply that you use that device for audio project data storage?
If those two things are true then disk performance should never be an issue, that just isn’t a real problem with SSD and audio data. Look for configuration issues, not disk issues (unless one of your disks is generating errors and causing a lot of retries).
Possibly even the underlying problem causing the crash is causing a software deadlock which is delaying some needed operation. But actual disk speed should not be the cause of the problem.
Your setup is not appropriate for RAID, nor is it needed.
Sadly not a good indicator, as you have mentioned. More for clarity than debating with you necessarily.
It isn’t even if the drive has ‘been close to full’ and had info removed, just regular usage with repeated adding and deleting of files (Caches, etc.) especially early drives would just grab the next unused sector, write to it, then it would get deleted (But not erased/cleared/trimmed) so it still had data on it, and as a result even if the disk showed empty to the file system, in order to write data to it you had to first erase the data that is there even though it had already been deleted.
Use of SATA TRIM command was added to 2.6.33 kernel (i.e. well over a decade), so I would not think that is much of an issue these days.
Even without trimming, or if you hit wear leveling faster than the TRIM command is invoked, an SSD should still be faster than an HDD, so I am extremely skeptical that the reported problem really has anything to do with disk performance.
The problem is I don’t believe all SSDs, as I mentioned particularly the cheaper earlier SSDs, support TRIM. And yea it would tank performance BAD, as in much worse than spinning disk drives, when you hit that threshold. (As in single digit MB transfer speeds were not unheard of IIRC)
You are correct most SSDs these days should support TRIM, and most OSes do as well, but on top of that most SSDs have their own garbage collection as well that helps prevent that. You are also correct in that it is unlikely that in this case that is going to be an issue, not impossible, just unlikely.
Seablade
Thank you all for your detailed and knowledgeable help. I ordered a new ssd anyway, hoping its a good one, as I figured if the original one is 6 years old, maybe it was getting unreliable and using a new disk should remove the possibility of problems with it. 
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.