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] [day] [month] [year] [list]
Message-ID: <CA+1E3rJ++2W3SNSfbyd7oGwwTt-4hzTCX4aiB_PxWELksggvFg@mail.gmail.com>
Date:   Thu, 30 Aug 2018 21:20:22 +0530
From:   Joshi <joshiiitr@...il.com>
To:     sandeen@...hat.com
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Defrag and delayed-allocation on Ext4

Thanks Eric. That explains. Donor file is out of the influence of
delayed allocation.
But now I wonder about target file which needs to be de-fragmented.
Defrag sounds tricky if part of this file is on-disk (i.e. extent
information is present) while remaining is yet to be written-back
(i.e. extents are yet to be allocated).
On Wed, Aug 29, 2018 at 10:20 PM Eric Sandeen <esandeen@...hat.com> wrote:
>
> On 8/29/18 11:22 AM, Joshi wrote:
> > Possibly a newbie question for the list, excuse my ignorance.
> > I saw e4defrag code, which fallocates a temporary file in the outset.
> >
> > I imagine that extents would not get allocated to the this file at
> > this time due to delayed-allocation feature (extent/block allocations
> > should happen post writes which seem to happen much later, during
> > extents copying between target-file and temporary-file).
> >
> > However, e4defrag needs extent information just after fallocate() to
> > determine whether it is wise to go-ahead with defrag process i.e.
> > whether new file is any less-fragmented than target one. I wonder how
> > this decision-making is possible if fallocate does not allocate
> > extents/blocks.
> >
> > I'd appreciate the thoughts.
>
> fallocate does not uses delayed allocation; it actually allocates
> specific blocks on disk before it returns.  So delayed allocation
> doesn't come into play for the temporary/donor file.
>
> (delayed allocation happens during writeback, but for fallocate the
> whole point is that there is no data written, it is simply an extent
> allocation which is flagged to show that it is a preallocated extent
> and that until it /is/ written to, reads should return 0s.)
>
> -Eric



-- 
Joshi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ