Ext4 is not known for being a robust file system and can cause corruption, plus as others have pointed out USB is fine for making a quick copy and then disconnecting, it is not suitable for RAID storage. Would it be possible to get an external eSATA enclosure? As for the file system, XFS is paramount in my experience, very fast and reliable.
On Thu, Aug 18, 2022 at 2:13 PM Rich Shepard <[email protected]> wrote: > On Thu, 18 Aug 2022, Ben Koenig wrote: > > > The log has generic input/output errors. You'll need to check your system > > logs at the time of the error. dmesg in particular will tell you if the > > USB connection reset because as Tomas mentioned USB connections tend to > be > > unreliable. > > Ben, > > Hadn't thought of dmesg: > ... > [9151279.099122] EXT4-fs warning (device sdd1): > htree_dirblock_to_tree:995: inode #2: lblock 0: comm gvfs-udisks2-vo: error > -5 reading directory block > [9151279.099132] EXT4-fs warning (device sdd1): > htree_dirblock_to_tree:995: inode #2: lblock 0: comm gvfs-udisks2-vo: error > -5 reading directory block > [9151279.099142] EXT4-fs warning (device sdd1): > htree_dirblock_to_tree:995: inode #2: lblock 0: comm gvfs-udisks2-vo: error > -5 reading directory block > [9151279.099151] EXT4-fs warning (device sdd1): > htree_dirblock_to_tree:995: inode #2: lblock 0: comm gvfs-udisks2-vo: error > -5 reading directory block > [9151279.099635] EXT4-fs error (device sdd1): ext4_find_entry:1455: inode > #2: comm pool: reading directory lblock 0 > [9151279.099638] EXT4-fs error (device sdc1): ext4_find_entry:1455: inode > #2: comm pool: reading directory lblock 0 > [9153896.496795] EXT4-fs error (device sdc1): ext4_find_entry:1455: inode > #2: comm gvfsd-trash: reading directory lblock 0 > [9153896.496819] EXT4-fs error (device sdc1): ext4_find_entry:1455: inode > #2: comm gvfsd-trash: reading directory lblock 0 > [9153896.496852] EXT4-fs error (device sdd1): ext4_find_entry:1455: inode > #2: comm gvfsd-trash: reading directory lblock 0 > [9153896.496869] EXT4-fs error (device sdd1): ext4_find_entry:1455: inode > #2: comm gvfsd-trash: reading directory lblock 0 > [9156467.969892] EXT4-fs (sdc1): error count since last fsck: 54 > [9156467.969897] EXT4-fs (sdd1): error count since last fsck: 30 > [9156467.969898] EXT4-fs (sdc1): initial error at time 1660653781: > ext4_find_entry:1455: inode 2 > [9156467.969901] EXT4-fs (sdd1): initial error at time 1660653781: > ext4_find_entry:1455 > [9156467.969902] EXT4-fs (sdc1): last error at time 1660826190: > ext4_find_entry:1455 > [9156467.969902] : inode 2 > [9156467.969904] : inode 2 > [9156467.969909] EXT4-fs (sdd1): last error at time 1660826190: > ext4_find_entry:1455: inode 2 > > So dmesg sees sdc1 and sdd1 while fdisk sees sdi and sdj. And I used UUIDs > in fstab. > > > Also, why is it that nobody ever posts the output of the mount command > > when they have filesystem errors? Nobody cares about your /etc/fstab. > > Seriously, it doesn't matter and we don't need to see it. 'mount |grep > > *media*' > > I looked at mount a few times; didn't think of posting it. Just now it > shows: > # mount > /dev/sda3 on / type ext4 (rw) > proc on /proc type proc (rw) > sysfs on /sys type sysfs (rw) > tmpfs on /dev/shm type tmpfs (rw) > /dev/sdb1 on /home type ext4 (rw) > /dev/sdb2 on /opt type ext4 (rw) > /dev/sdb3 on /data1 type ext4 (rw) > /dev/sda1 on /boot/efi type vfat (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/sdc1 on /media/data2 type ext4 (rw,noexec,nosuid,nodev) > /dev/sdd1 on /media/data3 type ext4 (rw,noexec,nosuid,nodev) > /dev/md0 on /media/backup type ext4 (rw) > gvfsd-fuse on /tmp/runtime-rshepard/gvfs type fuse.gvfsd-fuse > (rw,nosuid,nodev,user=rshepard) > > Thanks, > > Rich >
