* fstrim problem/bug
@ 2016-07-07 9:46 M G Berberich
2016-07-07 16:24 ` Henk Slager
0 siblings, 1 reply; 2+ messages in thread
From: M G Berberich @ 2016-07-07 9:46 UTC (permalink / raw)
To: linux-btrfs
Hello,
On a filesystem with 40 G free space and 54 G used, ‘fstrim -v’ gave
this result:
# fstrim -v /
/: 0 B (0 bytes) trimmed
After running balance it gave a more sensible
# fstrim -v /
/: 37.3 GiB (40007368704 bytes) trimmed
As far as I understand, fstrim should report any unused block to the
disk, so its controller can reuse these blocks. I expected ’fstrim -v’
to report about 40 G trimmed. The fact, that after balance fstrim
reports a sensible amount of trimmed bytes leads to the conclusion,
that fstrim on btrfs does not report unused blocks to the disk (as it
should), but only the blocks of unused chunks. As the fstrim-command
only does a ‘ioctl(fd, FITRIM, &range))’ this seems to be a bug in the
fstrim kernel-code.
In the field this means, that without regularly running balance,
fstrim does not work on btrfs.
MfG
bmg
--
„Des is völlig wurscht, was heut beschlos- | M G Berberich
sen wird: I bin sowieso dagegn!“ | mail@m-berberich.de
(SPD-Stadtrat Kurt Schindler; Regensburg) |
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: fstrim problem/bug
2016-07-07 9:46 fstrim problem/bug M G Berberich
@ 2016-07-07 16:24 ` Henk Slager
0 siblings, 0 replies; 2+ messages in thread
From: Henk Slager @ 2016-07-07 16:24 UTC (permalink / raw)
To: linux-btrfs
On Thu, Jul 7, 2016 at 11:46 AM, M G Berberich <btrfs@oss.m-berberich.de> wrote:
> Hello,
>
> On a filesystem with 40 G free space and 54 G used, ‘fstrim -v’ gave
> this result:
>
> # fstrim -v /
> /: 0 B (0 bytes) trimmed
>
> After running balance it gave a more sensible
>
> # fstrim -v /
> /: 37.3 GiB (40007368704 bytes) trimmed
>
> As far as I understand, fstrim should report any unused block to the
> disk, so its controller can reuse these blocks. I expected ’fstrim -v’
> to report about 40 G trimmed. The fact, that after balance fstrim
> reports a sensible amount of trimmed bytes leads to the conclusion,
> that fstrim on btrfs does not report unused blocks to the disk (as it
> should), but only the blocks of unused chunks. As the fstrim-command
> only does a ‘ioctl(fd, FITRIM, &range))’ this seems to be a bug in the
> fstrim kernel-code.
> In the field this means, that without regularly running balance,
> fstrim does not work on btrfs.
hmm, yes indeed I see this as well:
# btrfs fi us /
Overall:
Device size: 55.00GiB
Device allocated: 46.55GiB
Device unallocated: 8.45GiB
Device missing: 0.00B
Used: 39.64GiB
Free (estimated): 13.96GiB (min: 13.96GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 480.00MiB (used: 0.00B)
Data,single: Size:43.77GiB, Used:38.25GiB
/dev/sda1 43.77GiB
Metadata,single: Size:2.75GiB, Used:1.39GiB
/dev/sda1 2.75GiB
System,single: Size:32.00MiB, Used:16.00KiB
/dev/sda1 32.00MiB
Unallocated:
/dev/sda1 8.45GiB
# fstrim -v /
/: 9,3 GiB (10014126080 bytes) trimmed
# fallocate -l 5G testfile
# fstrim -v /
/: 4,3 GiB (4644130816 bytes) trimmed
Where the difference between 8.45GiB and 9,3 GiB comes from, I
currently don't understand.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-07-07 16:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-07 9:46 fstrim problem/bug M G Berberich
2016-07-07 16:24 ` Henk Slager
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).