search for: btrfs_compress_none

...); + }; +} + int do_defrag(int ac, char **av) { int fd; - int compress = 0; int flush = 0; u64 start = 0; u64 len = (u64)-1; @@ -156,15 +167,18 @@ int do_defrag(int ac, char **av) int verbose = 0; int fancy_ioctl = 0; struct btrfs_ioctl_defrag_range_args range; + int compress_type = BTRFS_COMPRESS_NONE; optind = 1; while(1) { - int c = getopt(ac, av, "vcfs:l:t:"); + int c = getopt(ac, av, "vc::fs:l:t:"); if (c < 0) break; switch(c) { case ''c'': - compress = 1; + compress_type = BTRFS_COMPRESS_ZLIB; + if (optarg) + compress_type...

...e = "lzo"; info->compress_type = BTRFS_COMPRESS_LZO; btrfs_set_opt(info->mount_opt, COMPRESS); + btrfs_set_fs_incompat(info, COMPRESS_LZO); } else if (strncmp(args[0].from, "no", 2) == 0) { compress_type = "no"; info->compress_type = BTRFS_COMPRESS_NONE; -- 1.7.8.6 -- 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

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

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

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

..._offset + hole_size - 1, 0); hole_em = alloc_extent_map(); @@ -4310,7 +4331,7 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) hole_em->ram_bytes = hole_size; hole_em->bdev = root->fs_info->fs_devices->latest_bdev; hole_em->compress_type = BTRFS_COMPRESS_NONE; - hole_em->generation = trans->transid; + hole_em->generation = root->fs_info->generation; while (1) { write_lock(&em_tree->lock); @@ -4323,17 +4344,14 @@ int btrfs_cont_expand(struct inode *inode, loff_t oldsize, loff_t size) hole_size - 1, 0); }...

For quite a while, I''ve experienced oddities with snapshotted Firefox _CACHE_00?_ files, whose checksums (and contents) would change after the btrfs snapshot was taken, and would even change depending on how the file was brought to memory (e.g., rsyncing it to backup storage vs checking its md5sum before or after the rsync). This only affected these cache files, so I didn''t give

Hi, The following patches add support for ext4 and btrfs to PV-GRUB. These patches are taken nearly verbatim from those provided by Fedora and Gentoo. We''ve been using these patches for the PV-GRUB images available in EC2 for some time now with no problems. Changes from v1: - Makefile has been changed to check the exit code from patch - The btrfs patch has been rebased to apply