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
| ||
|
Date: Sat, 26 Jun 2010 04:16:36 +0300 From: "Amir G." <amir73il@...rs.sourceforge.net> To: tytso@....edu Cc: Ext4 Developers List <linux-ext4@...r.kernel.org> Subject: Re: [PATCH, RFC] ext4: Store basic fs error information in the superblock On Thu, Jun 24, 2010 at 4:27 PM, <tytso@....edu> wrote: > True, thanks for pointing that out; the simplest way to solve this for > my purposes is to snapshot those superblock fields and restore them > after replaying the journal. > I guess that should work. I wonder why the ERROR_FS flag is not snapshotted on mount and the file system relies on the journal abort flag to re-set the ERROR_FS. > I wonder if the a better solution for this > particular use case is much larger ring buffer, and a hook into the > printk system which is guaranteed to record *everything*, even after a > panic or after the journal has been aborted and the file system has > been remounted read-only. > sounds like a good feature which would be hard to implement... BTW, I think that if the file system error behavior is set to "remount-ro" a file system with ERROR_FS, should be remounted read-only on mount time. this is the only way to prevent a file system from getting over corrupted and I don't see why there is no way to enforce this with existing error behavior options. We've implemented this logic at application level in our appliances. > For the patch I wrote, my intention was as a supplement to > /var/log/messages --- where s_first_error_time might be from long > after /var/log/messages had rolled over. So I was trying to solve a > somewhat different problem. (Hmm, actually, it would probably be good > to save both details about the first as well as the most recent error.) > One thing that is missing from the error info is its severity level. If I would have to save just one error info, it would be the first error after fsck (i.e. transition from healthy to sick file system), but I would override it if a message of higher severity occurs. Amir. -- 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