linux-kernel - Re: document ext3 requirements

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090104223756.GD1913@elf.ucw.cz>
Date:	Sun, 4 Jan 2009 23:37:56 +0100
From:	Pavel Machek <pavel@...e.cz>
To:	Theodore Tso <tytso@....edu>,
	"Alexander E. Patrakov" <patrakov@...il.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
	rdunlap@...otime.net, linux-doc@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: document ext3 requirements

On Sun 2009-01-04 13:38:34, Theodore Tso wrote:
> On Sun, Jan 04, 2009 at 06:35:41PM +0500, Alexander E. Patrakov wrote:
> >
> > Ext3 means either hardware that supports barriers (not sure how to  
> > check
> 
> Pretty much all modern disk drives supports barriers.  And note that
> w/o barriers ext3 has worked pretty well.  *If* you have a workload
> pushes your system into a mode which where it is very low on memory,
> so it is constantly paging/thrashing and you have a workload which is
> metadata intensive, and you crash the machine while it is thrashing,
> it is possible to end up in a situation where your filesystem is
> corrupted and you have to use e2fsck to correct the filesystem.  In

Are you sure you need to have thrashing? AFAICT metadata + fsync heavy
workload should be enough... and there were scripts to easily repeat
that.

> > Does this requirement apply to other  
> > journaling filesystems? Do I need journaling at all, given that I have  
> > an UPS on my desktop and a battery in the laptop?
> 
> Which requirement?  Barriers?  Most journaling filesystems simply
> enable barriers by default.  
> 
> And journalling is useful so that if your system crashes, say due to
> suspend and resume not working out, or the battery runs dry without
> your noticing it, you can avoid running fsck at boot time.  It's
> really more about shorting the boot time after a crash more than
> anything else.

Actually, journalling with barriers=0 should still be "safe" in case of
kernel crashes (*), right? Because if just kernel is dead, disk
firmware will still write the cache back, AFAICT.
									Pavel

(*) kernel crashes that do not involve writing random garbage to disk.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/