linux-ext4 - Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment

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: <BANLkTin4G1ERu+mfgf_9KFZNXtDd2kuYFg@mail.gmail.com>
Date:	Thu, 23 Jun 2011 07:27:13 -0400
From:	Greg Freemyer <greg.freemyer@...il.com>
To:	Kazuya Mio <k-mio@...jp.nec.com>
Cc:	Andreas Dilger <aedilger@...il.com>,
	Eric Sandeen <sandeen@...hat.com>, "Ted Ts'o" <tytso@....edu>,
	ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 01/11 RESEND] libe2p: Add new function get_fragment_score()

On Thu, Jun 23, 2011 at 7:16 AM, Greg Freemyer <greg.freemyer@...il.com> wrote:
> On Tue, Jun 21, 2011 at 7:28 AM, Kazuya Mio <k-mio@...jp.nec.com> wrote:
>> 2011/06/18 16:19, Andreas Dilger wrote:
>>>
>>> I was thinking about this, and am wondering if it makes sense to have an
>>> absolute score for fragmentation
>>> instead of a relative one?
>>>
>>> By absolute I mean something like fragments per MB or similar. A bad score
>>> might be anything>  1. For
>>> files smaller than 1 MB in size it would scale the ratio to the equivalent
>>> if the file was 1MB in size
>>> (e.g. a 16kB file with 4 fragments would have a score of 256, which is
>>> clearly bad).  Large files can
>>> have a score much less than 1, which is good.
>>
>> I think fragments per MB is easy to understand. I will fix the library
>> function
>> to "double e2p_get_fragscore(int fd)". To return fragments per MB, it will
>> get the number of extents and the total length of extents except the
>> following
>> special cases:
>> - The extent whose initialize status is different from the next extent
>> - There is a hole between the extent and the next extent
>> - The extent is a tail
>
> For a sparse file, can you explain why you treat the head and tail
> extents of a block group differently?
>
> The issue is totally symetric in my mind, so either include both or
> exclude both in my opinion.  The above description only excludes the
> block group tail extents.
>
> Greg

I forgot to say, fragments per MB is not a large enough unit in my mind.

A storage system that can transfer 100MB / sec , but takes 5 msecs to
seek and do a half rotation of the platter would spend 33% of its time
seeking if it had 1MB contiguous sections of data all over the drive.

Fragments per max extent really seems the only logical thng for
e4defrag to use in my mind.

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