[PATCH] Btrfs: make compress and nodatacow mount options mutually exclusive
If a filesystem is mounted with compression and then remounted by adding
nodatacow,
the compression is disabled but the compress flag is still visible.
Also, if a filesystem is mounted with nodatacow and then remounted with
compression,
nodatacow flag is still present but it's not active.
This patch:
- removes compress flags and notifies that the compression has been disabled if
the
filesystem is mounted with nodatacow
- removes nodatacow and nodatasum flags if mounted with compress.
Signed-off-by: Andrei Popa
---
fs/btrfs/super.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 073c236..6c72832 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -382,7 +382,15 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
btrfs_set_opt(info->mount_opt, NODATASUM);
break;
case Opt_nodatacow:
- printk(KERN_INFO "btrfs: setting nodatacow\n");
+ if (!btrfs_test_opt(root, COMPRESS) ||
+ !btrfs_test_opt(root, FORCE_COMPRESS)) {
+ printk(KERN_INFO "btrfs: setting
nodatacow, compression disabled\n");
+ } else {
+ printk(KERN_INFO "btrfs: setting nodatacow\n");
+ }
+ info->compress_type = BTRFS_COMPRESS_NONE;
+ btrfs_clear_opt(info->mount_opt, COMPRESS);
+ btrfs_clear_opt(info->mount_opt, FORCE_COMPRESS);
btrfs_set_opt(info->mount_opt, NODATACOW);
btrfs_set_opt(info->mount_opt, NODATASUM);
break;
@@ -397,10 +405,14 @@ int btrfs_parse_options(struct btrfs_root *root, char
*options)
compress_type = "zlib";
info->compress_type = BTRFS_COMPRESS_ZLIB;
btrfs_set_opt(info->mount_opt, COMPRESS);
+ btrfs_clear_opt(info->mount_opt, NODATACOW);
+ btrfs_clear_opt(info->mount_opt, NODATASUM);
} else if (strcmp(args[0].from, "lzo") == 0) {
compress_type = "lzo";
info->compress_type = BTRFS_COMPRESS_LZO;
btrfs_set_opt(info->mount_opt, COMPRESS);
+ btrfs_clear_opt(info->mount_opt, NODATACOW);
+ btrfs_clear_opt(info->mount_opt, NODATASUM);
btrfs_set_fs_incompat(info, COMPRESS_LZO);
} else if (strncmp(args[0].from, "no", 2) == 0) {
compress_type = "no";
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs fi df won't show total=
On Tue, 2012-07-10 at 00:52 +0300, Ilya Dryomov wrote: > mkfs creates those non-raid chunks for a pretty stupid reason, they > really shouldn't be there if you create a raid10 fs. Balance does the > right thing and removes them. Fixing this along with another mkfs > annoyance related to this one is on my TODO list. Hi Ilya, I've also studied this bug and found where the problem is, if this will help you: In mkfs.c, "make_root_dir" function creates the first system and metadata chunk: ret = btrfs_make_block_group(trans, root, bytes_used, BTRFS_BLOCK_GROUP_SYSTEM, BTRFS_FIRST_CHUNK_TREE_OBJECTID, 0, BTRFS_MKFS_SYSTEM_GROUP_SIZE); ret = btrfs_alloc_chunk(trans, root->fs_info->extent_root, &chunk_start, &chunk_size, BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA); BUG_ON(ret); ret = btrfs_make_block_group(trans, root, 0, BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA, BTRFS_FIRST_CHUNK_TREE_OBJECTID, chunk_start, chunk_size); And these chunks are created again in "create_raid_groups" function. Both functions, "make_root_dir" and "create_raid_groups" are called from "main" function. Andrei -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu
On Sun, 2012-06-17 at 06:14 +0200, rupert THURNER wrote: > >> Will result in anything reported in 'dmesg' output? > > [ 6431.514454] device label 388gb-data devid 1 transid 1086 /dev/sda6 > > [ 6431.514969] btrfs: disabling disk space caching > > [ 6431.514977] btrfs: force clearing of disk cache > tried the same with kernel versions from > http://kernel.ubuntu.com/~kernel-ppa/mainline/: > * 3.2.20 > * 3.4.0 > with version 3.4.0, i could delete one tiny file, but only one. peter > mentioned before to run the rm as root. yes, i did that, with all > kernel versions, the error was the same all the time. Have you tried to delete the files with "echo > file" ? This will empty the file without requiring a new metadata allocation. Andrei -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: Fix NOCOW file attribute
Hi, I've used the following to test the patch: rm a touch a chattr +C a dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 sync filefrag -v a dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 sync filefrag -v a Before the patch: ierdnac-hp btrfs # ./test + rm a + touch a + chattr +C a + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473536 8 eof a: 1 extent found + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473560 8 eof a: 1 extent found ierdnac-hp btrfs # After the patch: ierdnac-hp btrfs # ./test + rm a + touch a + chattr +C a + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 1+0 records in 1+0 records out 32768 bytes (33 kB) copied, 3.651e-05 s, 898 MB/s + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473560 8 eof a: 1 extent found + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 1+0 records in 1+0 records out 32768 bytes (33 kB) copied, 4.e-05 s, 702 MB/s + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473560 8 eof a: 1 extent found ierdnac-hp btrfs # My question is what is the expected behaviour for setting the chattr after the file is filed with bytes like this: rm a touch a # chattr +C a -> before chattr was here and we move it below dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 sync filefrag -v a chattr +C a dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 sync filefrag -v a Because in this case btrfs doesn't honour the NOCOW attribute: + rm a + touch a + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 1+0 records in 1+0 records out 32768 bytes (33 kB) copied, 3.5127e-05 s, 933 MB/s + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473544 8 eof a: 1 extent found + chattr +C a + dd if=/dev/zero of=a bs=32k conv=notrunc,nocreat count=1 1+0 records in 1+0 records out 32768 bytes (33 kB) copied, 3.4169e-05 s, 959 MB/s + sync + filefrag -v a Filesystem type is: 9123683e File size of a is 32768 (8 blocks, blocksize 4096) ext logical physical expected length flags 0 0 1473536 8 eof a: 1 extent found It's supposed to honour the NOCOW attribute or not ? On Sat, 2012-06-16 at 15:37 +0300, Andrei Popa wrote: > Adds BTRFS_INODE_NODATASUM to inode flags when setting NOCOW for a file > (chattr +C file). > In btrfs, NOCOW implies NODATASUM and without setting NODATASUM, btrfs > doesn't honour correctly the NOCOW attribute. > > Signed-off-by: Andrei Popa > --- > fs/btrfs/ioctl.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index 0e92e57..8a7be76 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -139,7 +139,7 @@ void btrfs_inherit_iflags(struct inode *inode, struct > inode *dir) > } > > if (flags & BTRFS_INODE_NODATACOW) > - BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW; > + BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW | > BTRFS_INODE_NODATASUM; > > btrfs_update_iflags(inode); > } > @@ -236,7 +236,7 @@ static int btrfs_ioctl_setflags(struct file *file, void > __user *arg) > else > ip->flags &= ~BTRFS_INODE_DIRSYNC; > if (flags & FS_NOCOW_FL) > - ip->flags |= BTRFS_INODE_NODATACOW; > + ip->flags |= BTRFS_INODE_NODATACOW | BTRFS_INODE_NODATASUM; > else > ip->flags &= ~BTRFS_INODE_NODATACOW; > -- Andrei Popa (+4) 0741.57.80.90 smime.p7s Description: S/MIME cryptographic signature
[PATCH] Btrfs: Fix NOCOW file attribute
Adds BTRFS_INODE_NODATASUM to inode flags when setting NOCOW for a file (chattr +C file). In btrfs, NOCOW implies NODATASUM and without setting NODATASUM, btrfs doesn't honour correctly the NOCOW attribute. Signed-off-by: Andrei Popa --- fs/btrfs/ioctl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 0e92e57..8a7be76 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -139,7 +139,7 @@ void btrfs_inherit_iflags(struct inode *inode, struct inode *dir) } if (flags & BTRFS_INODE_NODATACOW) - BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW; + BTRFS_I(inode)->flags |= BTRFS_INODE_NODATACOW | BTRFS_INODE_NODATASUM; btrfs_update_iflags(inode); } @@ -236,7 +236,7 @@ static int btrfs_ioctl_setflags(struct file *file, void __user *arg) else ip->flags &= ~BTRFS_INODE_DIRSYNC; if (flags & FS_NOCOW_FL) - ip->flags |= BTRFS_INODE_NODATACOW; + ip->flags |= BTRFS_INODE_NODATACOW | BTRFS_INODE_NODATASUM; else ip->flags &= ~BTRFS_INODE_NODATACOW; -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: Fix NOCOW file attribute
Btrfs doesn't honour correctly the NOCOW file attribute, this patch fixes this. NOCOW per file support has been added in e2fsprogs-1.42.4 Andrei Popa (1): Btrfs: Fix NOCOW file attribute fs/btrfs/ioctl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cannot remove files: "rm" gives "no space left on device", 3.2.0-24, ubuntu
https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21
On Sat, 2012-06-16 at 13:16 +0200, rupert THURNER wrote:
> how would i be able to delete something off this btrfs partition
> again? i saw the following messages in the archives which seem to be a
> little similar ... except a reboot and therfor a remount did not help:
> * http://article.gmane.org/gmane.linux.kernel/1265666/match=enospc
>
> rt@tv:~$ rm -rf /media/388gb-data/.Trash-1000/info/foto.trashinfo
> rm: cannot remove `/media/388gb-data/.Trash-1000/info/foto.trashinfo':
> No space left on device
>
> rt@tv:~$ btrfs filesystem df /media/388gb-data/
> Data: total=260.59GB, used=254.56GB
> System: total=32.00MB, used=24.00KB
> Metadata: total=128.00GB, used=120.01GB
>
> rt@tv:~$ sudo btrfs filesystem show /dev/sda6
> failed to read /dev/sr0
> Label: '388gb-data' uuid: 19223a9e-7840-4798-8ee4-02b5bf9c2899
> Total devices 1 FS bytes used 374.56GB
> devid1 size 388.62GB used 388.62GB path /dev/sda6
>
> rt@tv:~$ uname -a
> Linux tv 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
> i686 i686 i386 GNU/Linux
>
> the only snapshot is the one created during converting from ext4:
> $ sudo btrfs subvolume list /media/388gb-data/
> ID 256 top level 5 path ext2_saved
>
>
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=4480528, ...}) = 0
> mmap2(NULL, 262144, PROT_READ, MAP_PRIVATE, 3, 0x2bd) = 0xb7553000
> mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE, 3, 0x43a) = 0xb7552000
> close(3)= 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...})
> = 0
> lstat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fstatat64(AT_FDCWD,
> "/media/388gb-data/.Trash-1000/info/foto.trashinfo",
> {st_mode=S_IFREG|0644, st_size=56, ...}, AT_SYMLINK_NOFOLLOW) = 0
> unlinkat(AT_FDCWD,
> "/media/388gb-data/.Trash-1000/info/foto.trashinfo", 0) = -1 ENOSPC
> (No space left on device)
> open("/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7551000
> read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
> read(3, "", 4096) = 0
> close(3)= 0
> munmap(0xb7551000, 4096)= 0
> open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
> ENOENT (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
> mmap2(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7551000
> close(3)= 0
> write(2, "rm: ", 4rm: ) = 4
> write(2, "cannot remove `/media/388gb-data"..., 65cannot remove
> `/media/388gb-data/.Trash-1000/info/foto.trashinfo') = 65
> open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) =
> -1 ENOENT (No such file or directory)
> write(2, ": No space left on device", 25: No space left on device) = 25
> write(2, "\n", 1
> ) = 1
> _llseek(0, 0, 0xbfe0d210, SEEK_CUR) = -1 ESPIPE (Illegal seek)
> close(0)= 0
>
>
> rupert
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: add "nocompress" mount option
On Fri, 2012-06-15 at 12:50 +0200, David Sterba wrote: > mount -o compress,nocompress /dev /mnt > > Is it on or off? Yeah we can document that nocompress has higher > priority. But then I can't turn a nocompress option back to compress via > remount. This is possible with Arnd's patch. This happens for space_cache mount option: ierdnac-hp ~ # mount -o remount,space_cache,nospace_cache /mnt/btrfs/ Also there are mount option that can't be enabled/disabled by remount like: nobarrier - > "barrier" mount option doesn't exists ssd -> "nossd" doesn't exists noacl, user_subvol_rm_allowed, autodefrag, inode_cache, check_int, check_int_data. For some of these(ex: nossd,barrier) I think it would be usefull to have the reverse action. What do you think ? Andrei -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: add "nocompress" mount option
On Fri, 2012-06-15 at 12:50 +0200, David Sterba wrote: > that takes a different approach: setting compression to '=no' disables > compression. I prefer this over adding an extra option to disable. This > way there's no confusion if the compression is on or off. > > mount -o compress,nocompress /dev /mnt > > Is it on or off? Yeah we can document that nocompress has higher > priority. But then I can't turn a nocompress option back to compress via > remount. This is possible with Arnd's patch. Ok, how can we get his patch merged ? Thanks -- Andrei Popa NOC Manager - Nextgen Communications 0760 683 280 smime.p7s Description: S/MIME cryptographic signature
[PATCH] Btrfs: add "nocompress" mount option
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 filesystem mounted with
"compress" and we want to disable compression but we don't want to
umount and mount it.
Signed-off-by: Andrei Popa
---
fs/btrfs/ctree.h |1 +
fs/btrfs/super.c | 11 ++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 0236d03..c6e050a 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1567,6 +1567,7 @@ struct btrfs_ioctl_defrag_range_args {
#define BTRFS_MOUNT_CHECK_INTEGRITY(1 << 20)
#define BTRFS_MOUNT_CHECK_INTEGRITY_INCLUDING_EXTENT_DATA (1 << 21)
#define BTRFS_MOUNT_PANIC_ON_FATAL_ERROR (1 << 22)
+#define BTRFS_MOUNT_NOCOMPRESS (1 << 23)
#define btrfs_clear_opt(o, opt)((o) &= ~BTRFS_MOUNT_##opt)
#define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 0874dba..a78a6cf 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -280,7 +280,7 @@ enum {
Opt_enospc_debug, Opt_subvolrootid, Opt_defrag, Opt_inode_cache,
Opt_no_space_cache, Opt_recovery, Opt_skip_balance,
Opt_check_integrity, Opt_check_integrity_including_extent_data,
- Opt_check_integrity_print_mask, Opt_fatal_errors,
+ Opt_check_integrity_print_mask, Opt_fatal_errors, Opt_nocompress
Opt_err,
};
@@ -299,6 +299,7 @@ static match_table_t tokens = {
{Opt_compress_type, "compress=%s"},
{Opt_compress_force, "compress-force"},
{Opt_compress_force_type, "compress-force=%s"},
+ {Opt_nocompress, "nocompress"},
{Opt_ssd, "ssd"},
{Opt_ssd_spread, "ssd_spread"},
{Opt_nossd, "nossd"},
@@ -404,6 +405,7 @@ int btrfs_parse_options(struct btrfs_root *root,
char *options)
goto out;
}
+ btrfs_clear_opt(info->mount_opt, NOCOMPRESS);
btrfs_set_opt(info->mount_opt, COMPRESS);
if (compress_force) {
btrfs_set_opt(info->mount_opt, FORCE_COMPRESS);
@@ -413,6 +415,11 @@ int btrfs_parse_options(struct btrfs_root *root,
char *options)
pr_info("btrfs: use %s compression\n",
compress_type);
break;
+ case Opt_nocompress:
+ btrfs_clear_opt(info->mount_opt, FORCE_COMPRESS);
+ btrfs_clear_opt(info->mount_opt, COMPRESS);
+ btrfs_set_opt(info->mount_opt, NOCOMPRESS);
+ break;
case Opt_ssd:
printk(KERN_INFO "btrfs: use ssd allocation scheme\n");
btrfs_set_opt(info->mount_opt, SSD);
@@ -856,6 +863,8 @@ static int btrfs_show_options(struct seq_file *seq,
struct dentry *dentry)
else
seq_printf(seq, ",compress=%s", compress_type);
}
+ if (btrfs_test_opt(root, NOCOMPRESS))
+ seq_puts(seq, ",nocompress");
if (btrfs_test_opt(root, NOSSD))
seq_puts(seq, ",nossd");
if (btrfs_test_opt(root, SSD_SPREAD))
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[btrfs-progs] btrfs fi df output
Hello, I have a question regarding "btrfs filesystem df"output. # btrfs fi df /mnt/test Data: total=3.01GB, used=512.19MB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 <= What this means? For what is used? I've never seen this incremented Metadata, DUP: total=2.50GB, used=676.00KB Metadata: total=8.00MB, used=0.00<= the same question I have kernel 3.3.6 and btrfs-tools from git. #mkfs.btrfs /dev/mapper/vg-lvtest #mount /dev/mapper/vg-lvtest /mnt/test #dd if=/dev/zero of=/mnt/test/test.file bs=1M count=512 conv=fdatasync # btrfs fi df /mnt/test Data: total=3.01GB, used=512.19MB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=2.50GB, used=676.00KB Metadata: total=8.00MB, used=0.00 ierdnac-hp ~ # #umount /mnt/test These two chunks are the ones that appear below in btrfs-debug-tree ? Which ones ? In the three there is one 4MB andthree 8MB, one with 2 stripes. #btrfs-debug-tree /dev/mapper/vg-lvtest chunk tree leaf 20979712 items 12 free space 2557 generation 5 owner 3 fs uuid 6accfaf3-c88a-462e-85fc-35513d0b43d6 chunk uuid 65f22206-a9dd-4053-a660-61bc4ee0be12 item 0 key (DEV_ITEMS DEV_ITEM 1) itemoff 3897 itemsize 98 dev item devid 1 total_bytes 116912029696 bytes used 8627683328 item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 0) itemoff 3817 itemsize 80 chunk length 4194304 owner 2 type 2 num_stripes 1 stripe 0 devid 1 offset 0 item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 4194304) itemoff 3737 itemsize 80 chunk length 8388608 owner 2 type 4 num_stripes 1 stripe 0 devid 1 offset 4194304 item 3 key (FIRST_CHUNK_TREE CHUNK_ITEM 12582912) itemoff 3657 itemsize 80 chunk length 8388608 owner 2 type 1 num_stripes 1 stripe 0 devid 1 offset 12582912 item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) itemoff 3545 itemsize 112 chunk length 8388608 owner 2 type 34 num_stripes 2 stripe 0 devid 1 offset 20971520 stripe 1 devid 1 offset 29360128 Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] Btrfs-progs: support get/reset device stats via ioctl
On Thu, 2012-05-17 at 10:44 +0200, Stefan Behrens wrote: > On 05/16/2012 19:03, Andrei Popa wrote: > > It would be nice if this function could show the file names affected by > > errors, in case of a single, non-redundant drive, btrfs-progs should > > show what files are affected by errors. > > Then, an admin could restore only those files from backup. > > > > On Wed, 2012-05-16 at 18:50 +0200, Stefan Behrens wrote: > >> "btrfs device stats" is used to retrieve and print the device stats. > >> "btrfs device stats -z" is used to atomically retrieve, reset and > >> print the stats. > > > In case of disk errors, it is recommended to run scrub on that disk. It > checks the in-use disk contents for errors, repairs errors where > possible, and the scrub tool does print the paths and filenames of > errored files into the kernel log. In an automated script or for the usual user it would be easier to get the output from btrfs-progs scrub command with the affected files, instead from kernel log. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] Btrfs-progs: support get/reset device stats via ioctl
Hi, It would be nice if this function could show the file names affected by errors, in case of a single, non-redundant drive, btrfs-progs should show what files are affected by errors. Then, an admin could restore only those files from backup. On Wed, 2012-05-16 at 18:50 +0200, Stefan Behrens wrote: > "btrfs device stats" is used to retrieve and print the device stats. > "btrfs device stats -z" is used to atomically retrieve, reset and > print the stats. > > In order to share two utility functions between scrub and the dev stats > code, these two functions are moved to utils.c and renamed. > Since these functions are using open_file_or_dir(), and since the linking > against utils.o and common.o was different, open_file_or_dir() was moved > from common.c to utils.c. And since that function makes use of the > function dirfd(3), the required XOPEN version was raised from 6 to 7. > > Changes v1->v2: > - Remove a verbose printf() > - Cast u64 to unsigned long long for printf() > - Update the man page > > Changes v2->v3: > - Rebase on Chris' current master branch > - Split the patch into three seperate patches because after rebasing, > open_file_or_dir() was moved and additional changes had been necessary > > Stefan Behrens (3): > Btrfs-progs: move open_file_or_dir() to utils.c > Btrfs-progs: make two utility functions globally available > Btrfs-progs: add command to get/reset device stats via ioctl > > Makefile |4 +- > btrfsctl.c | 28 -- > cmds-balance.c |1 + > cmds-device.c| 113 > ++ > cmds-inspect.c |1 + > cmds-scrub.c | 72 +- > cmds-subvolume.c |1 + > commands.h |3 -- > common.c | 46 -- > ctree.h |6 +++ > ioctl.h | 27 + > man/btrfs.8.in | 14 +++ > print-tree.c |6 +++ > utils.c | 97 +- > utils.h |7 > 15 files changed, 275 insertions(+), 151 deletions(-) > delete mode 100644 common.c > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
brfs-progs patches
Hello, In the btrfs wiki ( https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories ) it says: "Hugo Mills maintains an "integration" branch of all the patches for the userspace tools that have been seen on the mailing list. There are two important branches in this repository. For "stable" commits that have been offered upstream, there's the for-chris branch. If you are writing patches for the userspace tools, you should probably develop against this branch [To make my life easier -Hugo]. This can be found with: $ git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git $ cd btrfs-progs-unstable $ git checkout for-chris " This year the repository has not been updated at all, is or this information still valid or it should be removed from the wiki ? There are some btrfs-progs patches send on the mailing-list which don't appear in Chris git for btrfs-progs. Does someone maintain a git tree with them ? Thanks, Andrei smime.p7s Description: S/MIME cryptographic signature
btrfs tools typo
In the latest btrfs tools from git it's a typo: ierdnac-hp ~ # btrfs|grep dafault btrfs subvolume get-dafault btrfs subvolume set-dafault ierdnac-hp ~ # Andrei -- Andrei Popa NOC Manager - Nextgen Communications 0760 683 280 smime.p7s Description: S/MIME cryptographic signature
