| 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: <4970AA6D.2040604@sandeen.net> Date: Fri, 16 Jan 2009 09:40:29 -0600 From: Eric Sandeen <sandeen@...deen.net> To: Valdis.Kletnieks@...edu CC: Eric Sandeen <sandeen@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, t-sato@...jp.nec.com Subject: Re: [PATCH] Allow SysRq emergency sync to thaw frozen filesystems Valdis.Kletnieks@...edu wrote: > On Thu, 15 Jan 2009 21:59:10 CST, Eric Sandeen said: > >> Oh, actually, I'd think not. If the freeze was done properly by the >> filesystem, all data was flushed, the fs was quiesced, and new IO was >> blocked. pdflush should never be visiting these... > > Yes, but a lot of 'if's - and usually you're reaching for sysrq-S precisely > *because* you suspect that stuff wasn't happening properly on its own... Actually, only one if - if the fs implemented freeze properly. Well, the use case I envision here is something like: # freeze /my/mount/point/to/fs/to/snapshot except oops, that wasn't mounted, and you just froze your root fs. I was thinking more recovery from admin error, not programming error... If we're using sysrq to work around any possible programming error, then we have a pretty tough job to make sure that it always works, no? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists