Roman Mamedov <mailto:r...@romanrm.net>
Monday, February 9, 2015 10:45 AM
On Mon, 9 Feb 2015 20:42:56 +0500
Roman Mamedov<r...@romanrm.net> wrote:
On Mon, 09 Feb 2015 10:26:33 -0500
"Devon B."<devo...@virtualcomplete.com> wrote:
If you don't mind me asking, what version kernel are you running and are
you using any special mount options?
Well actually I did not claim I have working discard through 'loop', but your
post made me curious.
$ sudo dd if=/dev/zero of=100g bs=1M seek=100000 count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00221052 s, 474 MB/s
$ sudo mkfs.ext4 100g
[...]
$ du -hsc 100g
133M 100g
133M total
$ sudo mount -o loop 100g /mnt/tmp1/
(then in a new terminal window):
$ cd /mnt/tmp1/
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 96G 60M 92G 1% /mnt/tmp1
$ sudo dd if=/dev/zero of=zerofile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.944377 s, 1.1 GB/s
$ sync
(back to the original one):
$ du -hsc 100g
1.2G 100g
1.2G total
(2nd window):
Forgot to add I also did 'rm zerofile' here, of course.
$ sudo fstrim .
(back to the original one):
$ du -hsc 100g
133M 100g
133M total
So it does work for me just fine even with 'loop'.
Kernel version 3.14.32, mount options
rw,noatime,nodiratime,compress=zlib,space_cache,inode_cache.
Roman Mamedov <mailto:r...@romanrm.net>
Monday, February 9, 2015 10:42 AM
On Mon, 09 Feb 2015 10:26:33 -0500
Well actually I did not claim I have working discard through 'loop',
but your
post made me curious.
$ sudo dd if=/dev/zero of=100g bs=1M seek=100000 count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00221052 s, 474 MB/s
$ sudo mkfs.ext4 100g
[...]
$ du -hsc 100g
133M 100g
133M total
$ sudo mount -o loop 100g /mnt/tmp1/
(then in a new terminal window):
$ cd /mnt/tmp1/
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 96G 60M 92G 1% /mnt/tmp1
$ sudo dd if=/dev/zero of=zerofile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.944377 s, 1.1 GB/s
$ sync
(back to the original one):
$ du -hsc 100g
1.2G 100g
1.2G total
(2nd window):
$ sudo fstrim .
(back to the original one):
$ du -hsc 100g
133M 100g
133M total
So it does work for me just fine even with 'loop'.
Kernel version 3.14.32, mount options
rw,noatime,nodiratime,compress=zlib,space_cache,inode_cache.
Devon B. <mailto:devo...@virtualcomplete.com>
Monday, February 9, 2015 10:26 AM
If you don't mind me asking, what version kernel are you running and
are you using any special mount options?
Here is a quick example:
# qemu-img create -f raw /btrfs/sub/raw.img 100G
Formatting '/btrfs/sub/raw.img', fmt=raw size=107374182400
# mkfs.ext4 /btrfs/sub/raw.img
...
# mount -o loop /btrfs/sub/raw.img /mnt/test
# du -hs /btrfs/sub/raw.img
1.7G /btrfs/sub/raw.img
# fstrim -v /mnt/test
/mnt/test: 105492688896 bytes were trimmed
# du -hs /btrfs/sub/raw.img
1.7G /btrfs/sub/raw.img
# dd if=/dev/zero of=/mnt/test/1GB count=1k bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.493057 s, 2.2 GB/s
# du -hs /btrfs/sub/raw.img
2.7G /btrfs/sub/raw.img
# rm -f /mnt/test/1GB
# fstrim -v /mnt/test
/mnt/test: 1186967552 bytes were trimmed
# du -hs /btrfs/sub/raw.img
2.7G /btrfs/sub/raw.img
# dd if=/dev/zero of=/mnt/test/1GB count=1k bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.467089 s, 2.3 GB/s
# du -hs /btrfs/sub/raw.img
3.7G /btrfs/sub/raw.img
# rm -f /mnt/test/1GB
# fstrim -v /mnt/test
/mnt/test: 1203761152 bytes were trimmed
# du -hs /btrfs/sub/raw.img
3.7G /btrfs/sub/raw.img
# du -hs /mnt/test
20K /mnt/test
So even though there is nothing in /mnt/test, the disk image is
consuming 3.7GB of space. Maybe you could test similarly with your
server if you have time on your hands.
Thanks!
Roman Mamedov <mailto:r...@romanrm.net>
Monday, February 9, 2015 1:40 AM
On Mon, 09 Feb 2015 00:17:49 -0500
I use KVM (QEMU) with discard pass-through from the VM guest
("discard=unmap"
option), with the VM images stored on Btrfs. It works just fine, the disk
space used for the image file does shrink when the guest OS issues
discards on
its FS. Maybe there is a difference in how KVM and the 'loop' module
submit
discards to Btrfs?
Devon B. <mailto:devo...@virtualcomplete.com>
Monday, February 9, 2015 12:17 AM
Looking to use btrfs with disk images that contain ext4, xfs, and other
possible filesystems. One of my main concerns is reclaiming disk space
when files are deleted on the disk image's filesystem. Using fstrim on
the mount point of the disk image or mounting the disk image (loop) with
discard doesn't appear to pass the freed blocks to btrfs.
The image file on the btrfs filesystem just keeps growing in size. When
hosting images on ext4, using fstrim or discard frees up the space on
the host filesystem (ext4).
I see discard is pretty well supported for btrfs to the underlying block
devices but is there any way to properly free space on the btrfs host
filesystem from overlying filesystems while they are online?
Thanks.
