linux-ext4 - Re: [PATCH v2] ext4: Try to better reuse recently freed space

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: <20130708115951.GC5988@quack.suse.cz>
Date:	Mon, 8 Jul 2013 13:59:51 +0200
From:	Jan Kara <jack@...e.cz>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
	Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: [PATCH v2] ext4: Try to better reuse recently freed space

On Mon 08-07-13 11:24:01, Lukáš Czerner wrote:
> On Mon, 8 Jul 2013, Jan Kara wrote:
> 
> > Date: Mon, 8 Jul 2013 10:56:03 +0200
> > From: Jan Kara <jack@...e.cz>
> > To: Lukas Czerner <lczerner@...hat.com>
> > Cc: linux-ext4@...r.kernel.org, jack@...e.cz,
> >     Andreas Dilger <adilger.kernel@...ger.ca>
> > Subject: Re: [PATCH v2] ext4: Try to better reuse recently freed space
> > 
> > On Mon 08-07-13 09:38:27, Lukas Czerner wrote:
> > > Currently if the block allocator can not find the goal to allocate we
> > > would use global goal for stream allocation. However the global goal
> > > (s_mb_last_group and s_mb_last_start) will move further every time such
> > > allocation appears and never move backwards.
> > > 
> > > This causes several problems in certain scenarios:
> > > 
> > > - the goal will move further and further preventing us from reusing
> > >   space which might have been freed since then. This is ok from the file
> > >   system point of view because we will reuse that space eventually,
> > >   however we're allocating block from slower parts of the spinning disk
> > >   even though it might not be necessary.
> > > - The above also causes more serious problem for example for thinly
> > >   provisioned storage (sparse images backed storage as well), because
> > >   instead of reusing blocks which are already provisioned we would try
> > >   to use new blocks. This would unnecessarily drain storage free blocks
> > >   pool.
> > > - This will also cause blocks to be allocated further from the given
> > >   goal than it's necessary. Consider for example truncating, or removing
> > >   and rewriting the file in the loop. This workload will never reuse
> > >   freed blocks until we continually claim and free all the block in the
> > >   file system.
> > > 
> > > Note that file systems like xfs, ext3, or btrfs does not have this
> > > problem. This is simply caused by the notion of global pool.
> > > 
> > > Fix this by changing the global goal to be goal per inode. This will
> > > allow us to invalidate the goal every time the inode has been truncated,
> > > or newly created, so in those cases we would try to use the proper more
> > > specific goal which is based on inode position.
> >   When looking at your patch for second time, I started wondering, whether
> > we need per-inode stream goal at all. We already do set goal in the
> > allocation request for mballoc (ar->goal) e.g. in ext4_ext_find_goal().
> > It seems strange to then reset it inside mballoc and I don't even think
> > mballoc will change it to something else now when the goal is per-inode and
> > not global.
> 
> Yes, we do set the goal in the allocation request and it is supposed
> to be the "best" goal. However sometimes it can not be fulfilled
> because we do not have any free block at "goal".
> 
> That's when the global (or per-inode) goal comes into play. I suppose
> that there was several reasons for that. First of all it makes it
> easier for allocator, because it can directly jump at the point
> where we allocated last time and it is likely that there is some
> free space to allocate from - so the benefit is that we do not have
> to walk all the space in between which is likely to be allocated.
  Yep, but my question is: If we have per-inode streaming goal, can you
show an example when the "best" goal will be different from the "streaming"
goal? Because from a (I admit rather quick) look at how each of these is
computed, it seems that both will point after the next allocated block in
case of streaming IO.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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