lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <55F332B6.3010107@yale.edu> Date: Fri, 11 Sep 2015 15:59:50 -0400 From: Chris Hunter <chris.hunter@...e.edu> To: linux-ext4@...r.kernel.org Subject: Re: e2fsck discrepancy with debugfs stat ? Hi Theodore, Thanks for the reply. Most of the e2fsck errors appear to have been uncommitted journal transactions. After stopping filesystem activity (hopefully to clear journal) a second dry-run e2fsck produced a much shorter list of errors. FYI, There was an entry "Links: 1 Blockcount: 8" reported by debugfs "stat" command is that same as i_links_count field ? thanks, chris hunter chris.hunter@...e.edu On 09/11/2015 01:55 PM, Theodore Ts'o wrote: > On Thu, Sep 10, 2015 at 11:03:57PM -0400, Chris Hunter wrote: >> Are there scenarios where e2fsck will report a deleted/unused inode but >> debugfs is able to read the inode structure ? > > When e2fsck reports that an inode is deleted/unused, it means that the > i_links_count field in the inode is zero. If that happens, it's > possible that the blocks previously associated with inode have been > reassigned, and so may contain someone else's love letters, medical > records, etc., and so the ext4 file system will report a corruption, > and allow you to read the inode, and e2fsck assumes that the > appropriate resolution to the problem is to clear the directory entry. > > (After all, you wouldn't want to accidentally commit a HIPPA > violation, when fines for violations range $100 to $50,000 per record, > would you? Not to mention potentially getting lots of terrible Yelp > reviews. :-) > >> However when I run command debugfs -c -R "stat /O/0/d19/131249395" <DEV>, I >> can retrieve inode contents. Further debugfs "dump" will successfully pull >> the contents (980 bytes) of the file entry. > > You can do anything with with debugfs. Debugfs doesn't care if the > i_links_count field is zero, so it will happily return whatever might > be pointed to by that inode. > > In terms of what might cause this, unless someone has been > manipulating file system structures using debugfs (for example, > "set_inode_field /O/0/d19/131249395 i_links_count 0"), it shouldn't > happen modulo hardware or software malfunctions / bugs. For example, > if you are using a SSD which isn't power failure protected (most > consumer-grade SSD's aren't) after a power failure, even if the file > system is properly using cache flush commands, if the SSD isn't set up > to make sure the SSD's metadata is properly saved to stable storage > after a power failure, the underlying file system can get corrupted. > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists