TurboStreetCar Posted July 2 Share Posted July 2 Hello, im having a problem with drive trim. My arrangement, is using Frigate for CCTV, with its own single hard drive, set up a separate pool outside of the array. I seem to have a problem when scheduled trim occurs, i get errors in the frigate docker log that the drive is out of space (The drive has over 1 TB of free space) when the scheduled Trim runs. Ive attached a segment of my unraid syslog, and a segment of the Frigate Container log that shows how the issue seems to be tied together. Trim, in scheduler is set to happen at 4:00AM on Tuesday. In the frigate log, at 4:42, i begin having the following errors in the log. 2024-07-02 04:42:47.136001501 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.136004621 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.137995300 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly 2024-07-02 04:42:47.138492208 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138495061 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138496483 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138500204 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138521748 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : [segment @ 0x5611227abc00] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138523115 [2024-07-02 04:42:47] ffmpeg.Garage_Side.record ERROR : Error writing trailer of /tmp/cache/Garage_Side@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138535799 [2024-07-02 04:42:47] watchdog.Garage_Side INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138550217 [2024-07-02 04:42:47] watchdog.Garage_Side INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:47.138551371 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 282908506, current: 282908506; changing to 282908507. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138552618 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Non-monotonous DTS in output stream 0:0; previous: 923672688, current: 923672688; changing to 923672689. This may result in incorrect timestamps in the output file. 2024-07-02 04:42:47.138571502 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138592472 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : [segment @ 0x5605b60e7040] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138616921 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : av_interleaved_write_frame(): No space left on device 2024-07-02 04:42:47.138638107 [2024-07-02 04:42:47] ffmpeg.Garage_Right.record ERROR : Error writing trailer of /tmp/cache/Garage_Right@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138662730 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : [segment @ 0x5637d95e1c00] Failure occurred when ending segment '/tmp/cache/[email protected]' 2024-07-02 04:42:47.138683980 [2024-07-02 04:42:47] watchdog.Garage_Right INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138707161 [2024-07-02 04:42:47] watchdog.Garage_Right INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:47.138729570 [2024-07-02 04:42:47] ffmpeg.Garage_Left.record ERROR : Error writing trailer of /tmp/cache/Garage_Left@%Y%m%d%H%M%S%z.mp4: No space left on device 2024-07-02 04:42:47.138751523 [2024-07-02 04:42:47] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:47.138773905 [2024-07-02 04:42:47] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.143311816 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.143367651 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.147280694 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147285087 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:42:57.147303503 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147342913 [2024-07-02 04:42:57] ffmpeg.Garage_Left.record ERROR : 2024-07-02 04:42:57.147407979 [2024-07-02 04:42:57] ffmpeg.Garage_Right.record ERROR : 2024-07-02 04:42:57.147410872 [2024-07-02 04:42:57] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147434966 [2024-07-02 04:42:57] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.147458919 [2024-07-02 04:42:57] watchdog.Garage_Right INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147483551 [2024-07-02 04:42:57] watchdog.Garage_Right INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:42:57.147506119 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:42:57.147526435 [2024-07-02 04:42:57] ffmpeg.Garage_Side.record ERROR : 2024-07-02 04:42:57.147576917 [2024-07-02 04:42:57] watchdog.Garage_Side INFO : Terminating the existing ffmpeg process... 2024-07-02 04:42:57.147578381 [2024-07-02 04:42:57] watchdog.Garage_Side INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:43:07.151769949 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.151827751 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:43:07.151849750 [2024-07-02 04:43:07] ffmpeg.Garage_Left.record ERROR : 2024-07-02 04:43:07.151884017 [2024-07-02 04:43:07] watchdog.Garage_Left INFO : Terminating the existing ffmpeg process... 2024-07-02 04:43:07.151904754 [2024-07-02 04:43:07] watchdog.Garage_Left INFO : Waiting for ffmpeg to exit gracefully... 2024-07-02 04:43:07.153795638 [2024-07-02 04:43:07] ffmpeg.Garage_Side.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.153850342 [2024-07-02 04:43:07] ffmpeg.Garage_Right.record ERROR : Could not write header for output file #0 (incorrect codec parameters ?): No space left on device 2024-07-02 04:43:07.153888710 [2024-07-02 04:43:07] ffmpeg.Garage_Side.record ERROR : Error initializing output stream 0:0 -- 2024-07-02 04:43:07.153915462 [2024-07-02 04:43:07] ffmpeg.Garage_Right.record ERROR : Error initializing output stream 0:0 -- These errors repeatedly continue until exactly 6:55AM. In the Unraid syslog, i have this entry: Jul 2 06:56:16 Backup root: /etc/libvirt: 32 GiB (34357972992 bytes) trimmed on /dev/loop3 Jul 2 06:56:16 Backup root: /var/lib/docker: 15.2 GiB (16307412992 bytes) trimmed on /dev/loop2 Jul 2 06:56:16 Backup root: /mnt/plex: 40.3 GiB (43228676096 bytes) trimmed on /dev/sdb1 Jul 2 06:56:16 Backup root: /mnt/deluge_pool: 233.3 GiB (250475106304 bytes) trimmed on /dev/nvme1n1p1 Jul 2 06:56:16 Backup root: /mnt/cctv: 1.2 TiB (1337126363136 bytes) trimmed on /dev/sde1 Jul 2 06:56:16 Backup root: /mnt/cache: 197.6 GiB (212154335232 bytes) trimmed on /dev/nvme0n1p1 So it would seem, that the scheduled TRIM of the CCTV drive, is what is causing the errors. The Frigate container, otherwise, runs completely error free up until the following week when it again runs the scheduled trim. I originally had the scheduled trim set to run on Monday morning at the same time, i moved the trim to Tuesday to verify they are related, and the problem in the frigate log followed to Tuesday. Is there a way to have the CCTV drive excluded from the scheduled trim? Quote Link to comment
JorgeB Posted July 2 Share Posted July 2 And that is a HDD? Post the output of: cat /boot/config/plugins/dynamix/ssd-trim.cron Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 2 minutes ago, JorgeB said: And that is a HDD? Post the output of: cat /boot/config/plugins/dynamix/ssd-trim.cron Yes, standard hard drive. Its a WD Purple surveillance drive. Output of the command you requested: root@Backup:~# cat /boot/config/plugins/dynamix/ssd-trim.cron # Generated TRIM schedule: 0 4 * * 2 /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron|logger &> /dev/null Quote Link to comment
JorgeB Posted July 2 Share Posted July 2 Post the output of: hdparm -I /dev/sdX | grep TRIM Replace X with correct letter Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 (edited) 3 minutes ago, JorgeB said: Post the output of: hdparm -I /dev/sdX | grep TRIM Replace X with correct letter Output of requested command: root@Backup:~# hdparm -I /dev/sde | grep TRIM * Data Set Management TRIM supported (limit 10 blocks) root@Backup:~# The drive configuration, incase it helps: Edited July 2 by TurboStreetCar Added Drive Config Quote Link to comment
JorgeB Posted July 2 Share Posted July 2 HDD reports TRIM support, is that an SMR drive? Purple drives used to be only CMR, but maybe that's no longer true. In any case, I don't know how to just not TRIM that drive, you would need to edit the script and modify it, but I'm afraid I can't help with that. Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 According to this link from WD: https://products.wdc.com/library/SpecSheet/ENG/product-brief-wd-purple-hdd.pdf Says the drive is CMR. Im not sure how that effects trim and accessibility. I feel like this problem should be effecting other people, but im not seeing anyone talk about it. Is it possible that the problem is with how the drive is configured? Would XFS vs BTRFS make a difference? Not sure which should be used, but when i set up the drive it seemed that people preferred XFS. One of the things i did while trying to figure this out, was turn off "autotrim", but it didn't seem to change the effect of the scheduled trim for the errors in the container. I dont get any other errors, from any other container or from any other storage device. However, other then the array, all the other devices are SSD's, so maybe thats why? Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 Looking in the Dynamix SSD Trim script, there is this portion: function is_hdd($disk) { $disk = explode('/',$disk); $disk = preg_replace('/^(sd[a-z]+|nvme[0-9]+n1)p?1$/','$1',end($disk)); return file_get_contents("/sys/block/$disk/queue/rotational")==1; } Ive run the following command: ***CCTV HDD - sde*** root@Backup:# cat /sys/block/sde/queue/rotational 1 ***Cache SSD - sdb*** root@Backup:# cat /sys/block/sdb/queue/rotational 0 So it would seem, that when Trim is scheduled and ran, in this function: write(_("TRIM operation started")."\n","\n","\n"); // trim btrfs, xfs exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); if (is_hdd($source)) continue; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } It checks to see if the disk is a "Spinning disk", and while im not super up on code, it would(should?) only continue the trim if the drive is a SSD. Although, it seems to "Continue" if that returns a "1", which would be a positive indication of a spinning drive. Shouldn't it be that any disk that returns a "1" would be skipped? OR is it desired to run trim on spinning drives as well as SSD's? I figured the "SSD trim" plugin, would be targeted towards SSD's and not HDD's. Also, it runs Trim on all of my drives, outside of array drives, so im not sure this check is actually effecting the trim at all? Quote Link to comment
JorgeB Posted July 2 Share Posted July 2 1 hour ago, TurboStreetCar said: Says the drive is CMR. Im not sure how that effects trim and accessibility First time I see TRIM on a CMR drive, for SMR it's been used before to move the data to SMR zones. Regarding the script, can't really help as coding is out of my wheel house. Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 4 hours ago, JorgeB said: First time I see TRIM on a CMR drive, for SMR it's been used before to move the data to SMR zones. Regarding the script, can't really help as coding is out of my wheel house. Should the trim script know whether a drive is CMR or SMR? Or are you referring to a manual operation? Quote Link to comment
Kilrah Posted July 2 Share Posted July 2 (edited) 6 hours ago, TurboStreetCar said: I feel like this problem should be effecting other people, but im not seeing anyone talk about it. HDDs that support TRIM aren't that common (and usually SMR of which use is discouraged for other reasons anyway), and people with some who do constant writing that has trouble with a temporary stall are probably even less common... Edited July 2 by Kilrah Quote Link to comment
_Shorty Posted July 2 Share Posted July 2 Add a couple of debugging statements to make sure things are being properly identified. function is_hdd($disk) { $disk = explode('/', $disk); $disk = preg_replace('/^(sd[a-z]+|nvme[0-9]+n1)p?1$/','$1',end($disk)); $is_hdd = file_get_contents("/sys/block/$disk/queue/rotational") == 1; write("Checking $disk: " . ($is_hdd ? "HDD\n" : "SSD\n")); // Debugging output return $is_hdd; } and foreach ($mounts as $mount) { [$target, $source] = explode(' ', $mount); write("Checking source: $source\n"); // Debugging output if (is_hdd($source)) continue; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } While it seems like it should be skipping that drive, it obviously isn't. This may help figure out where it is tripping up. Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 1 hour ago, Kilrah said: HDDs that support TRIM aren't that common (and usually SMR of which use is discouraged for other reasons anyway), and people with some who do constant writing that has trouble with a temporary stall are probably even less common... True, but alot of people are using Frigate, and id imagine some of them are recording to a standard HDD AND are running trim on a schedule. So i feel like i must be doing something wrong if no one else is having this issue. 14 minutes ago, _Shorty said: Add a couple of debugging statements to make sure things are being properly identified. "..." and "..." While it seems like it should be skipping that drive, it obviously isn't. This may help figure out where it is tripping up. Thanks i may add that to the script. Only problem, is i cant seem to find where its writing things to. It must have a log somewhere, but i cant find it. I've look all over the directories and cant find any output. The only output to the syslog is this: Jul 2 06:56:16 Backup root: /etc/libvirt: 32 GiB (34357972992 bytes) trimmed on /dev/loop3 Jul 2 06:56:16 Backup root: /var/lib/docker: 15.2 GiB (16307412992 bytes) trimmed on /dev/loop2 Jul 2 06:56:16 Backup root: /mnt/plex: 40.3 GiB (43228676096 bytes) trimmed on /dev/sdb1 Jul 2 06:56:16 Backup root: /mnt/deluge_pool: 233.3 GiB (250475106304 bytes) trimmed on /dev/nvme1n1p1 Jul 2 06:56:16 Backup root: /mnt/cctv: 1.2 TiB (1337126363136 bytes) trimmed on /dev/sde1 Jul 2 06:56:16 Backup root: /mnt/cache: 197.6 GiB (212154335232 bytes) trimmed on /dev/nvme0n1p1 But in the script it seems to write alot of things not shown here. Quote Link to comment
_Shorty Posted July 2 Share Posted July 2 Right. Well, you could make them echo statements instead and run it manually again. function is_hdd($disk) { $disk = explode('/', $disk); $disk = preg_replace('/^(sd[a-z]+|nvme[0-9]+n1)p?1$/', '$1', end($disk)); $is_hdd = file_get_contents("/sys/block/$disk/queue/rotational") == 1; echo "Checking $disk: " . ($is_hdd ? "HDD\n" : "SSD\n"); // Debugging output return $is_hdd; } and exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'", $mounts); foreach ($mounts as $mount) { [$target, $source] = explode(' ', $mount); echo "Checking source: $source\n"; // Debugging output if (is_hdd($source)) continue; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } and you should see output on screen like this: Checking source: /dev/sde Checking sde: HDD Checking source: /dev/sdb Checking sdb: SSD ... Quote Link to comment
TurboStreetCar Posted July 2 Author Share Posted July 2 1 hour ago, _Shorty said: Right. Well, you could make them echo statements instead and run it manually again. "..." and "..." and you should see output on screen like this: Checking source: /dev/sde Checking sde: HDD Checking source: /dev/sdb Checking sdb: SSD ... So I did a test, i changed the final function to this: exec("findmnt -lnt btrfs,xfs -o target,source|awk '\$2!~\"\\\\[\"{print \$1,\$2}'",$mounts); foreach ($mounts as $mount) { [$target,$source] = explode(' ',$mount); echo "before $source \r\n"; if (is_hdd($source)) continue; echo "continue $source \r\n"; write("$target: ... <i class='fa fa-spin fa-circle-o-notch'></i>\r"); $trim = exec("fstrim -v $target 2>/dev/null"); if ($trim) write("$trim on $source\r","\n"); else write("\r"); } And this was the output: root@Backup:/usr/local/emhttp/plugins/dynamix/scripts# php ssd_trim_test before /dev/md1p1 before /dev/nvme0n1p1 continue /dev/nvme0n1p1 before /dev/sde1 <------Does not continue before /dev/nvme1n1p1 continue /dev/nvme1n1p1 before /dev/sdb1 continue /dev/sdb1 before /dev/loop2 continue /dev/loop2 before /dev/loop3 continue /dev/loop3 So it seems when i run the script manually, it skips the drive, but when it runs on schedule, it definitely trims all the drives. So i guess, maybe its a different script that it runs on the schedule? Quote Link to comment
Kilrah Posted July 2 Share Posted July 2 3 hours ago, TurboStreetCar said: True, but alot of people are using Frigate, and id imagine some of them are recording to a standard HDD AND are running trim on a schedule. Sure, but it's very unlikely their drive will support TRIM Quote Link to comment
JorgeB Posted July 3 Share Posted July 3 9 hours ago, TurboStreetCar said: So it seems when i run the script manually, it skips the drive, but when it runs on schedule, it definitely trims all the drives. So i guess, maybe its a different script that it runs on the schedule? That doesn't make much sense, the scheduled script is the one I asked above, from /boot/config/plugins/dynamix/ssd-trim.cron, if you run the "TRIM now" option is the disk trimmed? Quote Link to comment
_Shorty Posted July 3 Share Posted July 3 It would appear that the one that runs as a cron job is a binary, and not the script in question. /sbin/fstrim It would seem that the binary's check for SSD vs rotational is not as robust. Perhaps it is actually checking for the presence of the trim command, and in the case of that HDD, it finds it, and so runs it. Quote Link to comment
JorgeB Posted July 3 Share Posted July 3 Just now, _Shorty said: It would appear that the one that runs as a cron job is a binary, and not the script in question. This should be the old one, can you check the output of cat /boot/config/plugins/dynamix/ssd-trim.cron for you? Quote Link to comment
_Shorty Posted July 3 Share Posted July 3 (edited) This is that cron job: 45 0 * * * /sbin/fstrim -a -v | logger &> /dev/null It's just running fstrim. It would seem he may be able to work around this issue by adding a mount option for that drive, at least according to the man page for fstrim. And adjusting the cron job's command line accordingly. https://man7.org/linux/man-pages/man8/fstrim.8.html Quote -I, --listed-in list Specifies a colon-separated list of files in fstab or kernel mountinfo format. All missing or empty files are silently ignored. The evaluation of the list stops after first non-empty file. For example: --listed-in /etc/fstab:/proc/self/mountinfo. Filesystems with "X-fstrim.notrim" mount option in fstab are skipped. Edited July 3 by _Shorty Quote Link to comment
JorgeB Posted July 3 Share Posted July 3 43 minutes ago, _Shorty said: This is that cron job That's the old one from v6.11, if you are on a newer release, do a dummy change in the TRIM scheduler settings and apply, it will start using the new script. Quote Link to comment
TurboStreetCar Posted July 3 Author Share Posted July 3 (edited) @_Shorty and @JorgeB : that back and fourth you guys just had is a little above my level, so im not sure. I just ran a "trim now" from the schedule page, and this was the results. So it appears the scheduled trim function, is separate from the script at /usr/local/emhttp/plugins/dynamix/scripts. I ran the command @JorgeB mentioned to check the other script and this was the output: root@Backup:/# cat /boot/config/plugins/dynamix/ssd-trim.cron # Generated TRIM schedule: 0 4 * * 2 /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim cron|logger &> /dev/null So it seems to reference the other script when ran. Is there a way i can find out what is actually running when the scheduled trim is triggered? It seems like it must be a different script/command then the script at that location, or else i wouldnt be getting mixed results. Is this potentially a bug that I've inadvertently discovered? Edited July 3 by TurboStreetCar Quote Link to comment
JorgeB Posted July 3 Share Posted July 3 1 hour ago, TurboStreetCar said: /usr/local/emhttp/plugins/dynamix/scripts/ssd_trim It should be running this script, I dont see the the cache pool being trimmed with the manual command, I assume it still exists? Also please post the complete diags just in case there's something out of the ordinary there. Quote Link to comment
_Shorty Posted July 3 Share Posted July 3 I think what he's saying is if you change the schedule to a different time and save it then it will update things to ensure it is using the latest script, rather than the old command. And if it uses the latest script it should stop trimming that hard drive, especially since the manual run you did from the schedule page skipped it. I'd give that a try. Quote Link to comment
JorgeB Posted July 3 Share Posted July 3 He already appears to be using the new script, I was referring to you, this is the old one, assuming you are on v6.12 or newer: 8 hours ago, _Shorty said: This is that cron job: 45 0 * * * /sbin/fstrim -a -v | logger &> /dev/null Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.