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]
Message-ID: <1187201812.396804.76130@k79g2000hse.googlegroups.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ