Playing with the trim/punch/discard support, I tried the patch below. It
see it getting invoked at times, but when I create a large file and then
delete it, I don''t see it getting invoked _enough_. And when I grep the
block device for the contents of the file, they''re still there.
I have a suspicion my added code is only getting invoked for
metadata/tree extents, not the actual data extents. What''d I miss?
diff --git a/extent-tree.c b/extent-tree.c
index fff219e..e6908ad 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -18,6 +18,7 @@
#include <linux/sched.h>
#include <linux/pagemap.h>
#include <linux/writeback.h>
+#include <linux/blkdev.h>
#include "hash.h"
#include "crc32c.h"
#include "ctree.h"
@@ -1743,6 +1744,22 @@ static int __free_extent(struct btrfs_trans_handle
*trans, struct btrfs_root
ret = update_block_group(trans, root, bytenr, num_bytes, 0,
mark_free);
BUG_ON(ret);
+
+
+ u64 map_length = num_bytes;
+ struct btrfs_multi_bio *multi = NULL;
+ ret = btrfs_map_block(&root->fs_info->mapping_tree, READ,
+ bytenr, &map_length, &multi, 0);
+ if (!ret) {
+ int i;
+ for (i=0; i< multi->num_stripes; i++) {
+ blkdev_issue_discard(multi->stripes[i].dev->bdev,
+ multi->stripes[i].physical >> 9,
+ min(map_length, num_bytes) >> 9,
+ NULL);
+ }
+ kfree(multi);
+ }
}
btrfs_free_path(path);
finish_current_insert(trans, extent_root);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2008-08-08 at 14:43 +0100, David Woodhouse wrote:> Playing with the trim/punch/discard support, I tried the patch below. It > see it getting invoked at times, but when I create a large file and then > delete it, I don''t see it getting invoked _enough_. And when I grep the > block device for the contents of the file, they''re still there. > > I have a suspicion my added code is only getting invoked for > metadata/tree extents, not the actual data extents. What''d I miss? >So you mkfs ; dd large file ; rm large file ; look for discards? Try rm large file ; sync ; sync; look for discards -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2008-08-08 at 09:56 -0400, Chris Mason wrote:> So you mkfs ; dd large file ; rm large file ; look for discards? > > Try rm large file ; sync ; sync; look for discardsYeah, I did that. The actual data extent isn''t getting removed. [root@dyn-226 /]# modprobe mtdram total_size=280000 [root@dyn-226 /]# modprobe mtdchar [root@dyn-226 /]# ftl_format /dev/mtd0 Partition size = 280000 kb, erase unit size = 128 kb, 1 transfer units Reserved 5%, formatted size = 262765 kb Erasing all blocks... +++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+++++++*+ Writing erase unit headers... format successful. [root@dyn-226 /]# modprobe ftl [root@dyn-226 /]# ~dwmw2/btrfs-progs-unstable/mkfs.btrfs /dev/ftla fs created label (null) on /dev/ftla nodesize 4096 leafsize 4096 sectorsize 4096 size 256.61MB Btrfs Btrfs v0.15 [root@dyn-226 /]# mount -tbtrfs /dev/ftla /mnt/spare [root@dyn-226 /]# cd /mnt/spare [root@dyn-226 spare]# cp /etc/services . [root@dyn-226 spare]# sync [root@dyn-226 spare]# hexdump -C /dev/ftla | grep /etc/services: 00c00000 23 20 2f 65 74 63 2f 73 65 72 76 69 63 65 73 3a |# /etc/services:| [root@dyn-226 spare]# dmesg -c > /dev/null [root@dyn-226 spare]# rm services [root@dyn-226 spare]# sync [root@dyn-226 spare]# dmesg num_bytes 4096, map_length 24576 Discard from stripe 0: 73808-8 FTL erase sector 73808 for 8 sectors num_bytes 4096, map_length 12288 Discard from stripe 0: 73832-8 FTL erase sector 73832 for 8 sectors num_bytes 4096, map_length 20480 Discard from stripe 0: 73816-8 FTL erase sector 73816 for 8 sectors [root@dyn-226 spare]# hexdump -C /dev/ftla | grep /etc/services: 00c00000 23 20 2f 65 74 63 2f 73 65 72 76 69 63 65 73 3a |# /etc/services:| [root@dyn-226 spare]# echo $((0xc00000/512)) 24576 -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2008-08-08 at 15:05 +0100, David Woodhouse wrote:> On Fri, 2008-08-08 at 09:56 -0400, Chris Mason wrote: > > So you mkfs ; dd large file ; rm large file ; look for discards? > > > > Try rm large file ; sync ; sync; look for discards > > Yeah, I did that. The actual data extent isn''t getting removed.Oh, you really did mean _two_ syncs. And then yes, I see why it isn''t working; mea culpa. __free_extent for 0xc00000-0xc65000 num_bytes 413696, map_length 8388608, stripes 1 Discard from stripe 0: 24576-808 bio too big device ftla (808 > 255) -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2008-08-08 at 15:10 +0100, David Woodhouse wrote:> On Fri, 2008-08-08 at 15:05 +0100, David Woodhouse wrote: > > On Fri, 2008-08-08 at 09:56 -0400, Chris Mason wrote: > > > So you mkfs ; dd large file ; rm large file ; look for discards? > > > > > > Try rm large file ; sync ; sync; look for discards > > > > Yeah, I did that. The actual data extent isn''t getting removed. > > Oh, you really did mean _two_ syncs. And then yes, I see why it isn''t > working; mea culpa. >The first sync commits the transaction and writes out the data. The second sync does the same thing, but this time it finds the old snapshot pending deletion and deletes it. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html