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]
Date:	Tue, 12 Jun 2012 08:32:17 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Saugata Das <saugata.das@...aro.org>
Cc:	Artem Bityutskiy <dedekind1@...il.com>,
	Saugata Das <saugata.das@...ricsson.com>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-mmc@...r.kernel.org, patches@...aro.org, venkat@...aro.org,
	Arnd Bergmann <arnd.bergmann@...aro.org>
Subject: Re: [PATCH 2/3] ext4: Context support

On Tue, Jun 12, 2012 at 05:51:22PM +0530, Saugata Das wrote:
> > The proof-of-concept patches seem to use the inode number as a way of
> > trying to group related writes, but what about at a larger level than
> > that?  For example, if we install a RPM or deb package where all of
> > the files will likely be replaced together, should that be given the
> > same context?
> 
> In this patch, context is used at file level based on inode number.
> So, in the above example, multiple contexts will be used for the
> directory, file updates during RPM installation.

Yes --- I was trying to explore if we should try to do better than
that.  For example, it would probably be a good idea (at minimum) to
hash some kind of partition id into the inode number to form the
context id.  It's probably rare that a MMC card would be partitioned,
but it might be much more common for other flash devices.

I could also imagine schemes where via some fcntl, additional file
descriptors could be joined to the context of another file descriptor.
Or maybe we have a scheme whereby some high-level, abstract, context
id's could be generated, and assigned to a group of file descriptors.

A hueristic where all file creations that occur within close together
in time are considered to be related might work well for the package
installation case, but might break down in others.  Which is why I
asked the question of what is the downside if the hueristics screw up,
and occasionally group together files/blocks that aren't related with
respect to when they are deallocated (since that *is* what the flash
devices care about, right?)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ