RPi4 & HDD corruption

  • I can appreciate, as Da Flex, posted that not writing down was to help prolong the life of MicroSD cards but could a switch be added to allow it to happen?

    <memorysize>0</memorysize> Just click the link and read...

    I was talking about A/V streaming buffer, because you didn't mentioned a specific buffer. Kodi's default setting includes Samba caching into RAM. Maybe you have to increase the "memorysize" parameter to keep the whole Samba cache in RAM.

  • <memorysize>0</memorysize> Just click the link and read...

    Sorry about misremembering your post.

    However, I don't want to keep the whole SAMBA cache in ram I want it on disk where (I think) it belongs.

    The link does give some interesting options which I can try. I'm not 100% certain exactly what some of them will do so it will be a bit more experimentation.

    Thanks for the link.

  • I read more about the cache and followed the links and as far as I can see this refers to video playback cache only not things like changing file names or adding new videos on.

    I can do a reboot every time I make a change but I'm baffled why no one else seems to be experiencing this problem. Maybe nobody has their drive connected to the Pi directly and access over LAN or something.

  • I've now tried with a couple of different disks, even formatted the smaller (600GB) one to Ext4 but still the same problem. Also tried plugging into the USB 2 port rather than the USB 3 - no difference.

    Looks like I'll be sticking with the RPi3 setup.

  • What's the result of <memorysize>0</memorysize> on advancedsettings.xml? That will write all the cache onto disk.

    It was worth a try so I tried it

    <cache>

    <memorysize>0</memorysize>

    <buffermode>3</buffermode>

    </cache>

    but it has no effect, and reading the info about it I wouldn't expect it to because this is for streams not file operations.

  • Content of /storage/.kodi/userdata/advancedsettings.xml should be:

    Code
    <advancedsettings version="1.0">
        <cache>
            <memorysize>0</memorysize>
            <buffermode>3</buffermode>
        </cache>
    </advancedsettings>

    Also try without the buffermode line.

  • I've now tried with a couple of different disks, even formatted the smaller (600GB) one to Ext4 but still the same problem. Also tried plugging into the USB 2 port rather than the USB 3 - no difference.

    Looks like I'll be sticking with the RPi3 setup.

    Hi,

    Did you tried another format type or only NTFS and Ext4?

    I'm not an expert in this matter, but I think is used a write buffer for disk write. Maybe that buffer sometimes didn't written to the disk correctly (power issue or another bug?).

    As I had issues with NTFS partitions in my PC under Linux (dual boot: W11 & Xubuntu for Android build environment), I'm using an ExFAT partition for data what I want to be accessible in the both OS. I you have some spare small disks, maybe is worth to try it.

    That "advancedsettings.xml" options are valid for the disk write buffer too, or is possible to be disabled in other way?

  • Content of /storage/.kodi/userdata/advancedsettings.xml should be:

    It was - I just quoted the cache bit.

    <buffermode>3</buffermode>

    is no buffering so removing it should have no effect but I'll try next week.

    I'm using an ExFAT partition for data what I want to be accessible in the both OS. I you have some spare small disks, maybe is worth to try it.

    I've only tried NTFS and Ext4 so far. ExFAT is supposed to be less robust than NTFS but I'll have a go. The thing that's really baffling me is why I get this on the RPi4 setup but not the RPi3.

  • another way: keep /storage on the SD, mount the hdd normal (e.g. as /var/media/storage2), delete the data directories (tvshows, videos, etc.) and make softlinks to the directories on your hdd under /storage

    tvshows -> /var/media/storage2/tvshows

    videos -> /var/media/storage2/videos

    etc...

    Only when you upload files over samba the hdd is written. If you still get corruption on the hdd, there is something wrong with your hardware.

  • I've only tried NTFS and Ext4 so far. ExFAT is supposed to be less robust than NTFS but I'll have a go. The thing that's really baffling me is why I get this on the RPi4 setup but not the RPi3.

    Maybe describe your setup in more detail, and how your shutting down. I don't routinely use external disks as everything is on a NAS via NFS, but I have used a USB-configuration with an NTFS disk when I am taking movies/shows on vacation and never had this problem with a RPi4.

    I don't see advanced settings having any bearing on this problem [they are really about video playback read caching]. As I understand it the source of corruption (or I guess what is corrupted) is written through the Samba service. It might also be good to describe the corruption, what your doing, what is happening, when it happens. Corruption is a bit non-descriptive, there is a lot that could be interpreted as corruption.

    It could be hardware, it could be how your shutting down, it could be that the shutdown is actually hanging (i.e. disk buffers are not flushed). But the short story is that Linux, if properly shutdown, will flush disk buffer caches to disk. It's been a while, but Linux used to even mention it something like "Syncing disks" and then "Power down" or "System halted", but most computers nowadays automatically power off so you hardly notice these messages on console.

  • It could be hardware, it could be how your shutting down

    Its definitely how I'm shutting down - just flip the power switch. Having said that I do the same with the Pi3s and no problem. I pull USB drives out of the port on Windows (you know the OS everyone loves to slag <G>) without safely ejecting and no problem . In addition I live in the Scottish Highlands where power cuts or voltage drops are not unknown.

    As far as not having the problem when taking a usb drive on holiday - how often have you written to the usb drive whilst its connected to the Pi4? If I leave it connected and do not change anything it works perfectly.

    However, I do have some good news

    Did you tried another format type or only NTFS and Ext4?

    ExFAT looks like the answer, at least with my experiments with a 600GB USB drive.

    I didn't try it because all my USB drives have been formatted to NTFS and all of the research I did said ExFAT is less stable. Stage 2 testing will commence after formatting the 6TB HDD.

    another way: keep /storage on the SD, mount the hdd normal (e.g. as /var/media/storage2), delete the data directories (tvshows, videos, etc.) and make softlinks to the directories on your hdd under /storage

    I'm not sure what this is meant to achieve.

  • Its definitely how I'm shutting down - just flip the power switch.

    Yeah, that will do it. Not surprised to be honest. But with that being said, so filesystems support mount options to force synchronous writes (which may be why exFAT is working, perhaps the default behavior):

    Quote

    sync

    All I/O to the filesystem should be done synchronously. In the case

    of media with a limited number of write cycles (e.g. some flash

    drives), sync may cause life-cycle shortening.

    Not sure if this is available for ntfs3 (it is a "common option" for all filesystems, so assuming it influences the OS cache), and the other thing to consider is disk-side write caching (but I think those might have power loss detection circuitry to flush that cache to disk, but not sure on that, hdparm usually can control that -- not sure if it is relevant for USB, honestly never had to do this).

  • ExFAT looks like the answer, at least with my experiments with a 600GB USB drive.

    ExFAT was developed for removable media. Probably the write cache is disabled if the system detect the exFAT partition.

    You can check the write cache status in SSH terminal: hdparm -W /dev/sda (if sda is your USB "big" disk).

    If not disabled by default, maybe is possible to disable the write cache: hdparm -W 0 /dev/sda - use it in autostart.sh.

    I have an 128GB USB stick for media storage (exFAT), and this is in my case the default write cache status:

  • Yeah, that will do it. Not surprised to be honest.

    ...

    the other thing to consider is disk-side write caching

    Neither would I be if stuff was still being written to disk but for one test I left it overnight. I thought about disk side caching, especially since you can hear it "chuntering" which is why I did the leave it overnight thing.

    VLouis

    Thanks for that, especially hdparm I'll be checking both NTFS & ExFAT formatted disks. You never know if I keep learning Linux at this rate I'll be an expert by the year 3000!

    I'll just be happy if I've found a solution.

  • VLouis

    Intriguing. The 600GB exFAT drive has write-caching enabled, the 6TB NTFS drive has

    /dev/sda1:

    write-caching = not supported

    Checked on the Pi3 and the 6TB drive on that also has write-caching = not supported

    Any thoughts?