linux-ext4 - Re: A proposal for making ext4's journal more SMR (and flash) friendly

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: <BCE18F0F-D8C9-41F3-A252-2E68C9A1421D@dilger.ca>
Date:	Fri, 10 Jan 2014 01:14:36 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: A proposal for making ext4's journal more SMR (and flash) friendly

On Jan 9, 2014, at 6:41, Theodore Ts'o <tytso@....edu> wrote:
> [Another design tangent: with SMR drives, it's clear that atime
> updates are going to be a big deal.  So the question is how much will
> our users really care about atime.  Can we just simply say, "use
> noatime", or should we think about some way of handling atime updates
> specially?  (For example, we could track atime updates separately, and
> periodically include in the journal a list of inode numbers and their
> real atimes.)  This is not something we should do early on --- it's
> another later optional enhancement --- but it is something to think
> about.

We already have noatime and relatime, since atime hurts on
spinning disks as well.  It wouldn't be impossible to do the atime updates in
the journal initially, and only write the inodes to their final resting place after
enough have been accumulated. 

I think when there are many atime updates together (e.g. "grep -r") it
will be reasonable to checkpoint them to the filesystem, and when
there are only a few those inodes could be rewritten to the journal.

I'm thinking the same could be done with data journaling for small files. 
It makes sense to write a small file's data to the journal, but write large
file data directly to its final resting place. 

Cheers, Andreas

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