similar to: [PATCH v2] Btrfs: return error when we specify wrong start to defrag

- Add incompat flag, otherwise btrfs-progs will report error when operating on btrfs filesystems mounted with lzo option. - Allow to turn on lzo compression for defrag operation: # btrfs filesystem defragment -c[zlib, lzo] <file> Note: "-c zlib" will fail, because that''s how getopt() works for optional arguments. Signed-off-by: Li Zefan

In support of the recently added capability to remount with lzo compression, provide a helper function to check the compression INCOMPAT flags when remounting with lzo compression, and set the flags if necessary. Also, implement the new helper function when defragmenting with explicit lzo compression and when setting the default subvolume. Signed-off-by: Mitch Harder

I noticed that btrfs fi defrag -c<method> can''t be used to compress files unless they are fragmented. This patch corrects the problem, by informing should_defrag_range if compression is enabled, and skipping tests for extent and adjacent extents if it is. Andrew Mahone (1): btrfs: ignore unfragmented file checks in defrag when compression enabled fs/btrfs/ioctl.c | 10

WARNING: This is not compatible with the previous lz4 patchset. If you''re using experimental compression that isn''t in mainline kernels, be prepared to backup and restore or decompress before upgrading, and have backups in case it eats data (which appears not to be a problem any more, but has been during development). These patches add lz4 and lz4hc compression

Hi, so here it is, LZ4 compression method inside btrfs. The patchset is based on top of current Chris'' for-linus + Andi''s snappy implementation + the fixes from Li Zefan. Passes xfstests and stresstests. I haven''t measured performance on wide range of hardware or workloads, rather wanted to publish the patches before I get distracted again. I''d like to ask

We currently have this problem where you can truncate pages that have not yet been written for an ordered extent. We do this because the truncate will be coming behind to clean us up anyway so what''s the harm right? Well if truncate fails for whatever reason we leave an orphan item around for the file to be cleaned up later. But if the user goes and truncates up the file and tries to

The rule originally comes from nocow writing, but snapshot-aware defrag is a different case, the extent has been writen and we''re not going to change the extent but add a reference on the data. So we''re able to allow such compressed extents to be merged into one bigger extent if they''re pointing to the same data. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> ---

Reserve metadata space for extent tree, checksum tree and root tree Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp 8/fs/btrfs/ctree.h 9/fs/btrfs/ctree.h --- 8/fs/btrfs/ctree.h 2010-04-18 10:26:38.327697818 +0800 +++ 9/fs/btrfs/ctree.h 2010-04-18 10:30:01.883697869 +0800 @@ -682,21 +682,15 @@ struct btrfs_space_info { u64 bytes_reserved; /* total bytes the allocator has

We''re going to use this flag EXTENT_DEFRAG to indicate which range belongs to defragment so that we can implement snapshow-aware defrag: We set the EXTENT_DEFRAG flag when dirtying the extents that need defragmented, so later on writeback thread can differentiate between normal writeback and writeback started by defragmentation. This patch is used for the latter one. Originally patch

Hi, xfs is supposed to detect the layout of a md-RAID devices when creating the file system, but it doesn?t seem to do that: # cat /proc/mdstat Personalities : [raid1] md10 : active raid1 sde[1] sdd[0] 499976512 blocks super 1.2 [2/2] [UU] bitmap: 0/4 pages [0KB], 65536KB chunk # mkfs.xfs /dev/md10p2 meta-data=/dev/md10p2 isize=512 agcount=4, agsize=30199892 blks

__ocfs2_page_mkwrite now is broken in handling file end. 1. the last page should be the page contains i_size - 1. 2. the len in the last page is also calculated wrong. So change them accordingly. Signed-off-by: Tao Ma <tao.ma at oracle.com> --- fs/ocfs2/mmap.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c index

I''m going to be removing hole extents in the near future so I wanted to make a sanity test for btrfs_get_extent to make sure I don''t break anything in the meantime. This patch just puts btrfs_get_extent through its paces by giving it a completely unreasonable mapping to look at and make sure it is giving us back maps that make sense. Thanks, Signed-off-by: Josef Bacik

Hello guys, I have some difficulties to understand what really are the numbers behing "df" and tune2fs. You'll find the output of tune2fs and df below, on which my maths are based. Here are my maths: A tune2fs on an ext3 FS tell me the FS size is 3284992 block large. It also tell me that the size of one block is 4096 (bytes if I'm not wrong?). So my maths tell me that the disk

If cow_file_range_inline fails with ENOSPC we abort the transaction which isn''t very nice. This really shouldn''t be happening anyways but there''s no sense in making it a horrible error when we can easily just go allocate normal data space for this stuff. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/inode.c | 5 ++++- 1 files changed, 4

Hello Eric, thank you for the quick reply and the explanations. > dumpe2fs -h output might show us that. Filesystem volume name: <none> Last mounted on: /opt/ssd Filesystem UUID: 75d6aae6-1746-4260-994b-148dfdb5af95 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

Thanks for you help. I also tried adding some other informations as you suggest: I can also take into account: - "Reserved block count: XXXXXXX" from tune2fs that gives me the number of blocks reserved for root - Reserved GDT blocks: XXX But I didn't thought about the FS journal. How can I gather information about it? (it's size and any other information?) 2013/9/16

I came across an old post comment yesterday (from http://echenh.blogspot.com/2010/04/how-to-extend-lvm-on-vmware-guest-os.html ) discussing the "hack" of LVM on Linux VM guests and whether it's better not to use it to simplify disk management. I've re-posted the comment below, does it sound reasonable? Is it better to not use LVM on Linux VM guests? --Russell

In btrfs if we mount with "compress" we have no way to disable compressing by remounting (mount -o remount /mnt/btrfs), only by unmounting and mounting without "compress". This patch adds "nocompress" mount option which can be used to remount the filesystem without compression: # mount -o remount,nocompress /mnt/btrfs This option is usefull in cases when we have a

On Sun, Dec 19, 2010 at 12:12:58PM +0100, Olivier Hault wrote: > For a while, I wonder if it would be possible to defrag guest fs > from the host. I can see two flavors a) offline defrag, b) online > defrag of the guest fs > > I there already solutions of works in progress to support those > operations ? We don't support this right now. However it is certainly something we