On 14 July 2015 at 21:15, Hugo Mills wrote:
> On Tue, Jul 14, 2015 at 09:09:00PM +0200, Patrik Lundquist wrote:
>> On 14 July 2015 at 20:41, Hugo Mills wrote:
>> > On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
>> >> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote
On Tue, Jul 14, 2015 at 09:09:00PM +0200, Patrik Lundquist wrote:
> On 14 July 2015 at 20:41, Hugo Mills wrote:
> > On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
> >> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
> >> >
> >> > Regardless of whether 1 or huge -t
On 14 July 2015 at 20:41, Hugo Mills wrote:
> On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
>> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>> >
>> > Regardless of whether 1 or huge -t means maximum defrag, however, the
>> > nominal data chunk size of 1 GiB me
On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
> >
> > Regardless of whether 1 or huge -t means maximum defrag, however, the
> > nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
> > should be co
Patrik Lundquist posted on Tue, 14 Jul 2015 13:57:07 +0200 as excerpted:
> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Regardless of whether 1 or huge -t means maximum defrag, however, the
>> nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
>> should b
On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Regardless of whether 1 or huge -t means maximum defrag, however, the
> nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
> should be considered ideally defragged at 31 extents. This is a
> departure from ext4,
On 25 June 2015 at 06:01, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Patrik Lundquist posted on Wed, 24 Jun 2015 14:05:57 +0200 as excerpted:
>
> > On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>
> If it's uint32 limited, either kill everything above that in both the
> documentation
Patrik Lundquist posted on Wed, 24 Jun 2015 14:05:57 +0200 as excerpted:
> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>> Patrik Lundquist posted on Wed, 24 Jun 2015 10:28:09 +0200 as
>> excerpted:
>>
>> AFAIK, it's set huge to defrag everything,
>
> It's set to 256K by default
On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
> Patrik Lundquist posted on Wed, 24 Jun 2015 10:28:09 +0200 as excerpted:
>
> AFAIK, it's set huge to defrag everything,
It's set to 256K by default.
> Assuming "set a huge -t to defrag to the maximum extent possible" is
> correct,
Patrik Lundquist posted on Wed, 24 Jun 2015 10:28:09 +0200 as excerpted:
> But what doesn't make sense to me is btrfs fi defrag; the -t option says
>
>-t
>defragment only files at least bytes big
>
> The -t value goes into struct
> btrfs_ioctl_defrag_range_args.exte
On 24 June 2015 at 05:20, Marc MERLIN wrote:
>
> Hello again,
>
> Just curious, is anyone seeing similar things with big VM images or other
> DBs?
> I forgot to mention that my vdi file is 88GB.
>
> It's surprising that it took longer to count the fragments than to actually
> defragment the file.
Hello again,
Just curious, is anyone seeing similar things with big VM images or other
DBs?
I forgot to mention that my vdi file is 88GB.
It's surprising that it took longer to count the fragments than to actually
defragment the file.
Or that it took 3 defrag runs to get down to 11K extents from
Hi Chris,
After our quick chat, I gave it a shot on 3.19.6, and things are better
than last time I tried.
legolas:/var/local/nobck/VirtualBox VMs# lsattr Win7/
---C Win7/Logs
---C Win7/Snapshots
---C Win7/Win7.vdi
---C Win7/Win7.png
---C
13 matches
Mail list logo
