search for: ext4_find_entry

...to get many I/O errors coming from the ext4 drive (sdc1) on dmesg, e.g.: Buffer I/O error on device sdc1, logical block 3084285 After that it looks like the ext4 HD was unmounted automatically and the btrfs HD made this BUG: usb 2-1: USB disconnect, device number 2 EXT4-fs error (device sdc1): ext4_find_entry:935: inode #109051908: comm bash: reading directory lblock 0 EXT4-fs error (device sdc1): ext4_find_entry:935: inode #109051905: comm bash: reading directory lblock 0 EXT4-fs error (device sdc1): ext4_find_entry:935: inode #2: comm umount: reading directory lblock 0 lost page write due to I/O er...

...1:0: timing out command, waited 1080s [3108269.919528] sd 2:0:1:0: [sdb] Unhandled error code [3108269.919535] sd 2:0:1:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_OK [3108269.919540] sd 2:0:1:0: [sdb] CDB: Read(10): 28 00 00 01 21 47 00 00 08 00 [3108269.919586] EXT4-fs error (device sdb1): ext4_find_entry: reading directory #2 offset 0 Removing the device, rescanning, and then re-adding it worked, but that moved the device to /dev/sdc instead. Which is fine, but it would be much better if it was /dev/sdb. Thanks for your help. :) On 5 March 2015 at 23:17, Marcelo Roccasalva < marcelo-centos a...

Hi all, We've having an issue at the moment where an iSCSI connection was temporarily lost on a few VMs running CentOS 6 on ESXi. The problem is, now that the iSCSI connection has returned, we are not able to remount the drive. At first the drive is read-only, so I tried '*mount -o remount,rw*' which didn't work (still read-only), so then I tried a '*umount*' (which

Currently, some new storage devices have the ability to do performance optimizations according to the type of data payload - say, file system metadata, time-stamps, sequential write in some granularity, random write and so on. For example, the latest eMMC 4.5 device can support the so-called ''Context Management'' and ''Data Tag Mechanism'' features. By receiving