occasional EXT4-fs errors on attached (USB) drive

  • Hi all,


    I have recently started to see occasional errors on my USB hard drive connected to my RPi running OMV 3.


    Can anyone give me some advice on what they might relate to? Is the hard drive going or can I safely ignore them. I have SMART monitoring running on the drive and haven't seen any reports of an issue.


    errors from syslog below...


    EXT4-fs error (device sda1): ext4_find_entry:1463: inode #2: comm smbd: reading directory lblock 0
    EXT4-fs warning (device sda1): htree_dirblock_to_tree:962: inode #23855105: lblock 0: comm smbd: error -5 reading directory block

  • You combine 'worst possible hardware' (a toy called Raspberry Pi) with a filesystem that's only suitable for situations without hardware issues. The average OMV user seems to love silent bit rot since otherwise at least btrfs would be used to be able to verify data integrity from time to time (so called scrubbing which will tell you if you suffer from corrupted data or not so you can try to restore corrupted data from your last backup).


    All you can do with ext4 now is running fsck over and over again and pray. Whether data is corrupted or not you find out only if it's too late already :)

  • You combine 'worst possible hardware' (a toy called Raspberry Pi) with a filesystem that's only suitable for situations without hardware issues

    @tkaiser I am using two external USB drives for backing up my ZFS pool via USBbackup plugin and a third one with eSATA interface. All drives are formatted with EXT4 filesystem. If EXT4 is not suitable which one should be preferred for this use case?
    I know that there are better possibilites to backup a pool (eg. with ZFS send), but at the moment I have no 2nd ZFS server system for this purpose.

    OMV 3.0.100 (Gray style)

    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1) - Fractal Design Node 304 -

    3x WD80EMAZ Snapraid / MergerFS-pool via eSATA - 4-Bay ICYCube MB561U3S-4S with fan-mod

  • If EXT4 is not suitable

    Sorry for the confusion. I was especially talking about the situation with Raspberries above. EXT4 and XFS can be considered the two most robust filesystems available on Linux. But they both base on the same assumption: everything down the path working well and 100% reliable.


    And this combined with unreliable hardware like Raspberry Pi (or almost all other el cheapo ARM thingies prone to underpowering and USB cable/connector crappiness nightmares) pretty often leads to situations where you only know that something happened but not how much your data is really affected. And that's where filesystems designed in this century come into play: btrfs and ZFS.


    If I can't use ZFS for data shares then these days I would choose btrfs (if kernel is 4.4 -- better 4.9 -- or above). For the checksumming feature alone (then of course setting up regular scrubs with notification) and even with multiple disks (then not implementing redundancy to increase availability but simply using the 'single' scheme for data similar to mdraid's linear mode)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!