https://bugzilla.kernel.org/show_bug.cgi?id=114821 --- Comment #8 from Lukas <dse.ssd@xxxxxxxxx> --- The command $ debugfs -c -R 'stat <1523>' /dev/sdb1 produces the following output: Inode: 1523 Type: regular Mode: 0644 Flags: 0x80000 Generation: 0 Version: 0x00000000 User: 1001 Group: 100 Size: 0 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x56b66f93 -- Sat Feb 6 17:11:31 2016 atime: 0x56b66f93 -- Sat Feb 6 17:11:31 2016 mtime: 0x4e4d75ac -- Thu Aug 18 16:27:24 2011 Size of extra inode fields: 0 EXTENTS: (END) Executing 'stat <1523>' command does not cause a head load cycle. As I understand, there are no blocks assigned to the inode. The file is an empty text file, so maybe it makes sense? I've created a new empty text file and it also has no blocks assigned to its inode, but it can be read and stat'ed with no problems. I've checked a few of the other inode numbers that appear in dmesg less frequently and - all of them point to empty text files! I would guess the reason why inode #1523 appears so often in the logs is because the file is in the root directory and gets listed each time the root is traversed. So, is it possible that something went wrong with just the zero-length files while I was copying my data to it? I did use ext2fsd on Windows 8.1 to copy some of the files... I just tested it again, and I can copy zero-length files to the drive using Windows and read them when mounted on linux with no problems. And since the zero-length files have no useful information (other than their file names, which I can still read) and have no blocks assigned to them can I now just remove them using debugfs? -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
