I am not sure if I should go to the DietPi forum, or if my issue is not specific about DietPi and I am in the right place. Anyway...
My setup consists of a Rock64 4G board connected to a WDLabs Pi drive. I have replaced the HDD cable delivered by (the now defunct) WDLabs with another interfaced with USB3. The WDLabs Pi drive has no SATA connector, see here. I have verified that the USB driver used for the disk is not UAS, in fact the HDD drive is using the usb-storage driver:
To test the above setup I have used a DietPi distro, which has always performed well on my Raspberries, copied to an SD card and updated with the latest release (6.21.1), to which I have applied the ayufan kernel 4.4.132-1075. Once the test was over, I patched the SPI to enable the USB boot, and then I restarted from scratch transferring the DietPi image directly on the HDD, using Rufus on a Windows machine. The DietPi partitioning scheme, therefore, has been replicated faithfully on the HDD, and indeed after the initial boot the /dev/sda7 partition (root) is properly extended to the maximum size of the disk (314 GB).
Differently from other Rock64 users, until now I haven't experienced any problem with the HDD while the system is running, thanks probably to the particular HDD I am using that was engineered specifically for the Raspberry environment. True, this host is only running Pi-hole, NUT and the Unifi Controller (+ MongoDB) right now, so the system load is not very high at the moment, but the performance is quite good except for the boot, where it takes ~50 seconds from the power on to present the login prompt.
My problem is instead with the reboot / poweroff actions, where 50% of the times the EXT4 filesystem is left in a dirty state, and where I have already experienced the loss / corruption of the /boot/dietpi directory, as well as the /boot/dietpi.txt file, to the point I have to boot the system from an SD card to repair / restore the partition. I have the suspect either the ayufan kernel, and/or the DietPi code dealing with its "ramdrive" are not giving enough time to the HDD to flush any pending writes, or even worst it cuts the power before the HDD is in a safe state. I'd say I am biased toward DietPi, as it's its files which are corrupted most of the times, while the rest of the HDD is sane (minus the fact EXT4 filesystem is in a dirty state). Probably not having /boot on a separate partition in this particular distro is not helping as much to avoid troubles, but this is just my opinion.
So: what am I doing wrong?
Have I forgotten to tune some parameters to better deal with the HDD? Did I make a mistake by putting the DietPi image directly on the HDD? Or is there really an issue on the Rock64, or on the DietPi distro? I have patched the shutdown sequence of the dietpi-ramdrive service to pause for 2 seconds and then run again the sync command to have the HDD some more time to flush any pending write, but it didn't cure the issue. I will try nevertheless to report all the above to the DietPi maintainer (Fourdee), but any hint would be very appreciated, thanks in advance.
My setup consists of a Rock64 4G board connected to a WDLabs Pi drive. I have replaced the HDD cable delivered by (the now defunct) WDLabs with another interfaced with USB3. The WDLabs Pi drive has no SATA connector, see here. I have verified that the USB driver used for the disk is not UAS, in fact the HDD drive is using the usb-storage driver:
Code:
[ 2.745235] usb-storage 5-1:1.0: USB Mass Storage device detected
[ 2.749781] scsi host0: usb-storage 5-1:1.0
[ 2.753639] usbcore: registered new interface driver usb-storageTo test the above setup I have used a DietPi distro, which has always performed well on my Raspberries, copied to an SD card and updated with the latest release (6.21.1), to which I have applied the ayufan kernel 4.4.132-1075. Once the test was over, I patched the SPI to enable the USB boot, and then I restarted from scratch transferring the DietPi image directly on the HDD, using Rufus on a Windows machine. The DietPi partitioning scheme, therefore, has been replicated faithfully on the HDD, and indeed after the initial boot the /dev/sda7 partition (root) is properly extended to the maximum size of the disk (314 GB).
Differently from other Rock64 users, until now I haven't experienced any problem with the HDD while the system is running, thanks probably to the particular HDD I am using that was engineered specifically for the Raspberry environment. True, this host is only running Pi-hole, NUT and the Unifi Controller (+ MongoDB) right now, so the system load is not very high at the moment, but the performance is quite good except for the boot, where it takes ~50 seconds from the power on to present the login prompt.
My problem is instead with the reboot / poweroff actions, where 50% of the times the EXT4 filesystem is left in a dirty state, and where I have already experienced the loss / corruption of the /boot/dietpi directory, as well as the /boot/dietpi.txt file, to the point I have to boot the system from an SD card to repair / restore the partition. I have the suspect either the ayufan kernel, and/or the DietPi code dealing with its "ramdrive" are not giving enough time to the HDD to flush any pending writes, or even worst it cuts the power before the HDD is in a safe state. I'd say I am biased toward DietPi, as it's its files which are corrupted most of the times, while the rest of the HDD is sane (minus the fact EXT4 filesystem is in a dirty state). Probably not having /boot on a separate partition in this particular distro is not helping as much to avoid troubles, but this is just my opinion.
So: what am I doing wrong?
Have I forgotten to tune some parameters to better deal with the HDD? Did I make a mistake by putting the DietPi image directly on the HDD? Or is there really an issue on the Rock64, or on the DietPi distro? I have patched the shutdown sequence of the dietpi-ramdrive service to pause for 2 seconds and then run again the sync command to have the HDD some more time to flush any pending write, but it didn't cure the issue. I will try nevertheless to report all the above to the DietPi maintainer (Fourdee), but any hint would be very appreciated, thanks in advance.