linux-kernel - Re: per device dirty throttling -v8

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>] [day] [month] [year] [list]

Date:	Wed, 15 Aug 2007 11:16:52 -0700
From:	david.balazic@...mes-softlab.com
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: per device dirty throttling -v8

On Aug 4, 10:15 pm, Arjan van de Ven <ar...@...radead.org> wrote:
> On Sat, 2007-08-04 at 12:47 -0700, Linus Torvalds wrote:
>
> > On Sat, 4 Aug 2007, J�rn Engel wrote:
>
> > > Given the choice between only "atime" and "noatime" I'd agree with you.
> > > Heck, I use it myself.  But "relatime" seems to combine the best of both
> > > worlds.  It currently just suffers from mount not supporting it in any
> > > relevant distro.
>
> > Well, we could make it the default for the kernel (possibly under a
> > "fast-atime" config option), and then people can add "atime" or "noatime"
> > as they wish, since mount has supported _those_ options for a long time.
>
> there is another trick possible (more involved though, Al will have to
> jump in on that one I suspect): Have 2 types of "dirty inode" states;
> one is the current dirty state (meaning the full range of ext3
> transactions etc) and "lighter" state of "atime-dirty"; which will not
> do the background syncs or journal transactions (so if your machine
> crashes, you lose the atime update) but it does keep atime for most
> normal cases and keeps it standard compliant "except after a crash".

Am I one of the few that thinks this would be a win-win solution ? :-(
I guess it requires a lot more coding than relatime.

Regards,
David Bala�ic

-
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/