Re: btrfs stuck on
I have a remarkably similar problem as Ask Bjørn Hansen. I have a 2TB btrfs filesystem on a SATA drive, on top of an msdos partition table, partition 1, without any form of RAID. I have been using it to make backups using rsync like this: 1) snapshot the previous backup subvolume 2) rsync into the new snapshot 3) If we are overwriting a previous backup level, drop that previous subvolume and rename this one into it's place. I keep 8 levels in tower-of-hanoi strategy. It's the same backup script I've used for the last 5 years, except I removed the rsync --link-dest and added in the btrfs snapshotting, just because dropping a subvolume is so damn quick compared to deleting all the files. After about 400 GB of backups taken all in the same day, but having already dropped probably 12 or 13 subvolumes after snapshotting, I get the behavior. The behavior is: *) After mounting, things are usually ok for 20 seconds or so, then it starts *) The disk activity lite burns constantly *) btrfs-cleaner is fairly high up in 'top' *) Read/writes to the device are painfully slow *) I cannot unmount the device, nor cleanly shutdown. *) Once the system froze hard, no mouse cursor movement, not even the reset button worked. I'm running linux 3.8.3 pulled from git, so no distribution mods or patches. Happy to run any tests. -Mike [not on this list, so need to be on the reply] -- 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: The -c option of btrfs qgroup limit
Hi Koen, On 27.03.2013 00:36, Koen De Wit wrote: The btrfs qgroup limit command has an option -c which means limit amount of data after compression. Whether this option is specified or not, I seem to be able to write more well-compressible data than the specified limit. I was expecting that omitting the -c option would never allow me to write more data than specified by the limit. Am I missing something? Which difference in behavior should I expect from the -c option? Today: none. In the future: The one you describe. That option is planned but not implemented. We should have mentioned that in the qgroup usage, I agree. -Jan -- 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
The -c option of btrfs qgroup limit
Hello Koen, Although we offer '-c' option for btrfs qgroup limit, it has been not implemented yet. So until now, btrfs quota just limits the real space that writes to the space. Thanks, Wang -- 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: multiple btrfsck runs
On Sun, 17 Mar 2013, cwillu cwi...@cwillu.com wrote: On Sat, Mar 16, 2013 at 6:46 AM, Russell Coker russ...@coker.com.au wrote: On Sat, 16 Mar 2013, cwillu cwi...@cwillu.com wrote: On Sat, Mar 16, 2013 at 6:02 AM, Russell Coker russ...@coker.com.au wrote: Is it expected that running btrfsck more than once will keep reporting errors? Without options, btrfsck does not write to the disk. The man page for the version in Debian doesn't document any options. The source indicates that --repair might be the one that's desired, is that correct? Yes. However, unless something is actually broken, or you've been advised by a developer, I'd stick with btrfs scrub. -- 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 I've got a filesystem that causes a kernel panic and can't even get to the scrub stage, so btrfsck is necessary. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703211 While this is an upstream bug, I've filed the above Debian bug report about it. Sometimes in such situations the DD will fix the bug and send the patch upstream. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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-progs: root_item generation_v2 is out of sync after btrfsck
reproducing steps:
mkfs.btrfs /dev/dm-2 -f
mount /dev/dm-2 /btrfs
umount /btrfs
btrfs check /dev/dm-2 --repair
mount /dev/dm-2 /btrfs
btrfs: mismatching generation and generation_v2 found in root item. This root
was probably mounted with an older kernel. Resetting all new fields.
btrfs-debug-tree shows change in uuid
root data bytenr 29425664 level 0 dirid 0 refs 1 gen 43
uuid 293596e8-7888-eb4c-9134-6df9db996fe5
---
root data bytenr 29417472 level 0 dirid 0 refs 1 gen 46
uuid 38d16308-fc48-0645-ac49-748f96634148
Signed-off-by: Anand Jain anand.j...@oracle.com
---
root-tree.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/root-tree.c b/root-tree.c
index c10d068..4454147 100644
--- a/root-tree.c
+++ b/root-tree.c
@@ -69,6 +69,7 @@ int btrfs_update_root(struct btrfs_trans_handle *trans,
struct btrfs_root
int ret;
int slot;
unsigned long ptr;
+ u32 old_size;
path = btrfs_alloc_path();
BUG_ON(!path);
@@ -79,6 +80,18 @@ int btrfs_update_root(struct btrfs_trans_handle *trans,
struct btrfs_root
l = path-nodes[0];
slot = path-slots[0];
ptr = btrfs_item_ptr_offset(l, slot);
+ /*
+ * If the btrfs-progs is newer and kernel is at
+ * generation_v1 then we don't touch v2 items
+ * otherwise when kernel is at same or greater
+ * version compared with btrfs-progs then update
+ * the needed
+ */
+ old_size = btrfs_item_size_nr(l, slot);
+ if (old_size = sizeof(*item)) {
+ btrfs_set_root_generation_v2(item,
+ btrfs_root_generation(item));
+ }
write_extent_buffer(l, item, ptr, sizeof(*item));
btrfs_mark_buffer_dirty(path-nodes[0]);
out:
--
1.8.1.227.g44fe835
--
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
btrfsck infinite loop
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703474 The above Debian bug report has the details of a btrfsck infinite loop problem I'm having. I initially reported it as an i386 bug because it didn't seem to appear on AMD64. But then I realised that on AMD64 it merely runs for longer before looping. git pull http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I've just used the above command to get the latest btrfsck source, compiled it and run it. The resulting btrfsck has now used 97 minutes of CPU time which is about 94 minutes since the last time it gave any output. Below is the last output of btrfsck before it entered the 100% CPU loop. leaf parent key incorrect 566530048 bad block 566530048 leaf parent key incorrect 566534144 bad block 566534144 leaf parent key incorrect 566538240 bad block 566538240 leaf parent key incorrect 566542336 bad block 566542336 leaf parent key incorrect 566546432 bad block 566546432 leaf parent key incorrect 566550528 bad block 566550528 leaf parent key incorrect 566554624 bad block 566554624 leaf parent key incorrect 566558720 bad block 566558720 leaf parent key incorrect 566579200 bad block 566579200 leaf parent key incorrect 567844864 bad block 567844864 leaf parent key incorrect 567853056 bad block 567853056 -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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 and the steadily lit LED
Hi guys, After having received strong advice from the people in this list to upgrade my kernel to the latest one, I have installed 3.8.0-14-generic #24-Ubuntu SMP x86_64 on several (4) machines. In the hope of improving systems speed I had also removed all snapshots then defragged the FSes - the snapshots have been recreated since, as I use the excellent SuSE Snapper tool. But well, all 4 machines are still slow like hell. All of them are used for quite basic daily tasks - web browsing, email, typical LibreOffice tasks, nothing very mysterious there, no specific heavy DB work. All machines have 64-bits Linuxes (either Ubuntu 12.10 or 13.04ß), with decent amounts of RAM - 2 GB to 4 GB - and disks filled less than 75% With such a setup, I would expect any decent filesystem to deliver excellent performance. Still, all of my machines are slow like hell and I'm most of the time in mode « Working my patience while waiting for the HD LED to go off ». I haven't noticed any real-life noticeable improvement upgrading the kernels from 3.5.x to 3.8.x So I'm wondering... -- Swâmi Petaramesh sw...@petaramesh.org http://petaramesh.org PGP 9076E32E Ne cherchez pas : Je ne suis pas sur Facebook. -- 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: No space left on device although df reports only 55% in use
Hi again, I wonder if this is the intended behaviour or some known issue? Otherwise I could provide a tool written by a friend of mine which can trigger this issue within a few minutes on a a fresh btrfs partition. Its basically a file-system aging tester, which replays some real-world logs taken from NFS file servers. Regards, Clemens -- 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: No space left on device although df reports only 55% in use
On Wed, Mar 27, 2013 at 12:28:23AM +0100, Clemens Eisserer wrote: I am using a btrfs loopback mounted file with lzo-compression on Linux-3.7.9, and I ran into No space left on device messages, although df reports only 55% of space is used: # touch testfile touch: cannot touch `testfile': No space left on device # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 32768000 17383924 14649172 55% /home/ce/anditest # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Your metadata is close to full -- we need quite a lot of working space to CoW into. You (probably) have the full disk allocated to chunks, and too much is allocated to data; not enough to metadata. You need o balance, with a filter for the unused data chunks. See the section in the FAQ on the wiki about full filesystems. (Sorry for not finding the link, I'm on a restricted connection right now) Hugo. Metadata: total=8.00MB, used=0.00 Any ideas what is going wrong here? Thank you in advance, Clemens -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Gentlemen! You can't fight here! This is the War Room! --- signature.asc Description: Digital signature
[PATCH 0/5 v5] access to backup-sb and btrfs' multipath aware
We need a mechanism to tell when to use the backup super_block. To do this it needs a frame-work, and the patch #2 and #3 below provides the same without change in the logic. Its been found and posted to the list that check_mounted needs access to the backup-sb. so patch #3 adds flags parameter to the function btrfs_scan_one_device so that _only_ check_mounted can set the flag to access the backup-sb. patch#4 below is to enable and disable acecss to backup-sb for only certain threads v4-v5: Rebase with integration-20130321 and with my own changes (patch #1) Allow check_mounted thread-path to use backup-sb v3-v4: Fixed some warnings introduced by patch #3 below, sorry my mistake. v2-v3: Accepts David and Eric review, which would result in disabled access to backup-superblock by default. Dropped the patch [PATCH 3/3] btrfs-progs: use BTRFS_SCAN_BACKUP_SB flag in btrfs_scan_one_device Introduced a new patch [PATCH 3/3] btrfs-progs: disable using backup superblock by default v1-v2: Accepts Eric and Zach review. Separates fix into 3 patches for easy logical understanding Anand Jain (5): btrfs-progs: make btrfs dev scan multi path aware btrfs-progs: Introduce flag BTRFS_SCAN_REGISTER to replace run_ioctl btrfs-progs: Introduce flag BTRFS_SCAN_BACKUP_SB for btrfs_read_dev_super btrfs-progs: introduce passing flags to btrfs_scan_one_device btrfs-progs: disable using backup superblock by default cmds-device.c | 57 + cmds-replace.c | 2 +- disk-io.c | 15 ++- disk-io.h | 3 ++- find-root.c| 9 ++--- utils.c| 57 +++-- utils.h| 8 +--- volumes.c | 6 -- volumes.h | 2 +- 9 files changed, 109 insertions(+), 50 deletions(-) -- 1.8.1.227.g44fe835 -- 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 2/5 v5] btrfs-progs: Introduce flag BTRFS_SCAN_REGISTER to replace run_ioctl
Introduce flag BTRFS_SCAN_REGISTER to replace the parameter run_ioctl
which controls calling the function btrfs_register_one_device().
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c | 4 ++--
disk-io.c | 3 ++-
find-root.c | 3 ++-
utils.c | 17 +
utils.h | 7 ---
5 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index b8d05fd..edff0bf 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -218,9 +218,9 @@ static int cmd_scan_dev(int argc, char **argv)
printf(Scanning for Btrfs filesystems\n);
if(checklist)
- ret = btrfs_scan_block_devices(1);
+ ret = btrfs_scan_block_devices(BTRFS_SCAN_REGISTER);
else
- ret = btrfs_scan_one_dir(/dev, 1);
+ ret = btrfs_scan_one_dir(/dev, BTRFS_SCAN_REGISTER);
if (ret){
fprintf(stderr, ERROR: error %d while scanning\n,
ret);
return 18;
diff --git a/disk-io.c b/disk-io.c
index be4abb8..6a03e9c 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -835,7 +835,8 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, const
char *path,
}
if (total_devs != 1) {
- ret = btrfs_scan_for_fsid(fs_devices, total_devs, 1);
+ ret = btrfs_scan_for_fsid(fs_devices, total_devs,
+ BTRFS_SCAN_REGISTER);
if (ret)
goto out;
}
diff --git a/find-root.c b/find-root.c
index 810d835..16920ed 100644
--- a/find-root.c
+++ b/find-root.c
@@ -110,7 +110,8 @@ static struct btrfs_root *open_ctree_broken(int fd, const
char *device)
}
if (total_devs != 1) {
- ret = btrfs_scan_for_fsid(fs_devices, total_devs, 1);
+ ret = btrfs_scan_for_fsid(fs_devices, total_devs,
+ BTRFS_SCAN_REGISTER);
if (ret)
goto out;
}
diff --git a/utils.c b/utils.c
index 3a0d444..15645c1 100644
--- a/utils.c
+++ b/utils.c
@@ -927,7 +927,8 @@ int check_mounted_where(int fd, const char *file, char
*where, int size,
/* scan other devices */
if (is_btrfs total_devs 1) {
- if((ret = btrfs_scan_for_fsid(fs_devices_mnt, total_devs, 1)))
+ if((ret = btrfs_scan_for_fsid(fs_devices_mnt, total_devs,
+ BTRFS_SCAN_REGISTER)))
return ret;
}
@@ -1039,7 +1040,7 @@ void btrfs_register_one_device(char *fname)
close(fd);
}
-int btrfs_scan_one_dir(char *dirname, int run_ioctl)
+int btrfs_scan_one_dir(char *dirname, u64 flags)
{
DIR *dirp = NULL;
struct dirent *dirent;
@@ -1128,7 +1129,7 @@ again:
BTRFS_SUPER_INFO_OFFSET);
close(fd);
- if (ret == 0 run_ioctl 0) {
+ if (ret == 0 flags BTRFS_SCAN_REGISTER) {
btrfs_register_one_device(fullpath);
}
}
@@ -1152,13 +1153,13 @@ fail:
}
int btrfs_scan_for_fsid(struct btrfs_fs_devices *fs_devices, u64 total_devs,
- int run_ioctls)
+ u64 flags)
{
int ret;
- ret = btrfs_scan_block_devices(run_ioctls);
+ ret = btrfs_scan_block_devices(flags);
if (ret)
- ret = btrfs_scan_one_dir(/dev, run_ioctls);
+ ret = btrfs_scan_one_dir(/dev, flags);
return ret;
}
@@ -1391,7 +1392,7 @@ int set_label(const char *btrfs_dev, const char *label)
set_label_mounted(btrfs_dev, label);
}
-int btrfs_scan_block_devices(int run_ioctl)
+int btrfs_scan_block_devices(u64 flags)
{
struct stat st;
@@ -1469,7 +1470,7 @@ scan_again:
num_devices,
BTRFS_SUPER_INFO_OFFSET);
close(fd);
- if (ret == 0 run_ioctl 0) {
+ if (ret == 0 flags BTRFS_SCAN_REGISTER) {
btrfs_register_one_device(fullpath);
}
}
diff --git a/utils.h b/utils.h
index 4dcdc31..1de5143 100644
--- a/utils.h
+++ b/utils.h
@@ -23,6 +23,7 @@
#include ctree.h
#define BTRFS_MKFS_SYSTEM_GROUP_SIZE (4 * 1024 * 1024)
+#define BTRFS_SCAN_REGISTER(1ULL 1)
int make_btrfs(int fd, const char *device, const char *label,
u64 blocks[6], u64 num_bytes, u32 nodesize,
@@ -36,9 +37,9 @@ int btrfs_add_to_fsid(struct btrfs_trans_handle *trans,
u64 block_count, u32 io_width, u32 io_align,
u32 sectorsize);
int btrfs_scan_for_fsid(struct btrfs_fs_devices *fs_devices, u64 total_devs,
- int run_ioctls);
+ u64 flags);
void btrfs_register_one_device(char *fname);
-int
[PATCH 1/5 v5] btrfs-progs: make btrfs dev scan multi path aware
We should avoid using non multi-path (mp) path for mp disks
As of now there is no good way (like api) to check that.
A workaround way is to check if the O_EXCL open is unsuccessful.
This is safe since otherwise the BTRFS_IOC_SCAN_DEV ioctl would
fail if the disk-path can not be opened with the flag O_EXCL set.
This patch also includes some (error) print format changes related
to the btrfs dev scan..
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c | 53 +++--
utils.c | 31 ---
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index 41e79d3..b8d05fd 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -185,7 +185,7 @@ static const char * const cmd_scan_dev_usage[] = {
static int cmd_scan_dev(int argc, char **argv)
{
- int i, fd, e;
+ int i, fd, e, ret = 0;
int checklist = 1;
int devstart = 1;
@@ -197,6 +197,21 @@ static int cmd_scan_dev(int argc, char **argv)
devstart += 1;
}
+ fd = open(/dev/btrfs-control, O_RDWR);
+ e = errno;
+ if (fd 0) {
+ FILE *mfd = popen(lsmod | grep btrfs, r);
+ char buf[16];
+
+ if (fread (buf, 1, sizeof (buf), mfd) 0)
+ fprintf(stderr, ERROR: failed to open \
+ /dev/btrfs-control - %s\n, strerror(e));
+ else
+ fprintf(stderr, ERROR: btrfs kernel module \
+ is not loaded\n);
+ return 10;
+ }
+
if(argc=devstart){
int ret;
@@ -210,20 +225,30 @@ static int cmd_scan_dev(int argc, char **argv)
fprintf(stderr, ERROR: error %d while scanning\n,
ret);
return 18;
}
+ printf(done\n);
return 0;
}
- fd = open(/dev/btrfs-control, O_RDWR);
- if (fd 0) {
- perror(failed to open /dev/btrfs-control);
- return 10;
- }
-
+ printf(Scanning for Btrfs in\n);
for( i = devstart ; i argc ; i++ ){
+ int fdt;
struct btrfs_ioctl_vol_args args;
- int ret;
+ printf( %s , argv[i]);
+ fflush(stdout);
- printf(Scanning for Btrfs filesystems in '%s'\n, argv[i]);
+ /*
+* If for a multipath (mp) disk user provides the
+* non-mp path then open with flag O_EXCL will fail,
+* (also ioctl opens with O_EXCL), So test it before
+* calling ioctl.
+*/
+ fdt = open(argv[i], O_RDONLY|O_EXCL);
+ if (fdt 0) {
+ perror(ERROR);
+ ret = -1;
+ continue;
+ }
+ close(fdt);
strncpy_null(args.name, argv[i]);
/*
@@ -235,15 +260,15 @@ static int cmd_scan_dev(int argc, char **argv)
e = errno;
if( ret 0 ){
- close(fd);
- fprintf(stderr, ERROR: unable to scan the device '%s'
- %s\n,
- argv[i], strerror(e));
- return 11;
+ fprintf(stderr, ERROR: unable to scan - %s\n,
+ strerror(e));
+ ret = -1;
}
+ printf(found\n);
}
close(fd);
- return 0;
+ return ret;
}
static const char * const cmd_ready_dev_usage[] = {
diff --git a/utils.c b/utils.c
index a4f7b06..3a0d444 100644
--- a/utils.c
+++ b/utils.c
@@ -1105,25 +1105,32 @@ again:
if (!S_ISBLK(st.st_mode)) {
continue;
}
- fd = open(fullpath, O_RDONLY);
+ fd = open(fullpath, O_RDONLY|O_EXCL);
if (fd 0) {
/* ignore the following errors:
ENXIO (device don't exists)
ENOMEDIUM (No medium found -
like a cd tray empty)
+ EBUSY (when mp disk is opened
+ using non-mp path).
*/
- if(errno != ENXIO errno != ENOMEDIUM)
+ if(errno != ENXIO errno != ENOMEDIUM
+ errno != EBUSY)
fprintf(stderr, failed to read %s: %s\n,
fullpath, strerror(errno));
continue;
}
+ close(fd);
+
+ fd = open(fullpath, O_RDONLY);
ret = btrfs_scan_one_device(fd, fullpath, tmp_devices,
[PATCH 5/5 v5] btrfs-progs: disable using backup superblock by default
except for check_mounted rest of the function thread
should have the access to the backup SB disabled.
this patch will just do that.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
disk-io.c | 2 +-
find-root.c | 2 +-
utils.c | 2 +-
volumes.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 82c3b66..589b37a 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -881,7 +881,7 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, const
char *path,
disk_super = fs_info-super_copy;
ret = btrfs_read_dev_super(fs_devices-latest_bdev,
disk_super, sb_bytenr,
- BTRFS_SCAN_BACKUP_SB);
+ 0ull);
if (ret) {
printk(No valid btrfs found\n);
goto out_devices;
diff --git a/find-root.c b/find-root.c
index eac3d79..27512df 100644
--- a/find-root.c
+++ b/find-root.c
@@ -153,7 +153,7 @@ static struct btrfs_root *open_ctree_broken(int fd, const
char *device)
disk_super = fs_info-super_copy;
ret = btrfs_read_dev_super(fs_devices-latest_bdev,
disk_super, BTRFS_SUPER_INFO_OFFSET,
- BTRFS_SCAN_BACKUP_SB);
+ 0ull);
if (ret) {
printk(No valid btrfs found\n);
goto out_devices;
diff --git a/utils.c b/utils.c
index a2001de..b9b675d 100644
--- a/utils.c
+++ b/utils.c
@@ -923,7 +923,7 @@ int check_mounted_where(int fd, const char *file, char
*where, int size,
/* scan the initial device */
ret = btrfs_scan_one_device(fd, file, fs_devices_mnt,
total_devs, BTRFS_SUPER_INFO_OFFSET,
- 0ull);
+ BTRFS_SCAN_BACKUP_SB);
is_btrfs = (ret = 0);
/* scan other devices */
diff --git a/volumes.c b/volumes.c
index a18b219..2de69af 100644
--- a/volumes.c
+++ b/volumes.c
@@ -228,7 +228,7 @@ int btrfs_scan_one_device(int fd, const char *path,
}
disk_super = (struct btrfs_super_block *)buf;
ret = btrfs_read_dev_super(fd, disk_super, super_offset,
- BTRFS_SCAN_BACKUP_SB);
+ 0ull);
if (ret 0) {
ret = -EIO;
goto error_brelse;
--
1.8.1.227.g44fe835
--
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 4/5 v5] btrfs-progs: introduce passing flags to btrfs_scan_one_device
check_mounted would need to check backup SB to see if the
device is mounted to accommodate the situation when the
primary SB is corrupted (even in multi dev btrfs).
so we need flag to communicate to btrfs_read_dev_super
to check backup SB.
this patch will just introduce the flag with access
to backup SB disable.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-replace.c | 2 +-
disk-io.c | 2 +-
find-root.c| 3 ++-
utils.c| 9 ++---
volumes.c | 2 +-
volumes.h | 2 +-
6 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/cmds-replace.c b/cmds-replace.c
index 6397bb5..ab34388 100644
--- a/cmds-replace.c
+++ b/cmds-replace.c
@@ -280,7 +280,7 @@ static int cmd_start_replace(int argc, char **argv)
goto leave_with_error;
}
ret = btrfs_scan_one_device(fddstdev, dstdev, fs_devices_mnt,
- total_devs, BTRFS_SUPER_INFO_OFFSET);
+ total_devs, BTRFS_SUPER_INFO_OFFSET, 0ull);
if (ret = 0 !force_using_targetdev) {
fprintf(stderr,
Error, target device %s contains filesystem, use '-f'
to force overwriting.\n,
diff --git a/disk-io.c b/disk-io.c
index 8d68c2e..82c3b66 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -827,7 +827,7 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, const
char *path,
fprintf(stderr, Warning, could not drop caches\n);
ret = btrfs_scan_one_device(fp, path, fs_devices,
- total_devs, sb_bytenr);
+ total_devs, sb_bytenr, 0ull);
if (ret) {
fprintf(stderr, No valid Btrfs found on %s\n, path);
diff --git a/find-root.c b/find-root.c
index 0b08358..eac3d79 100644
--- a/find-root.c
+++ b/find-root.c
@@ -102,7 +102,8 @@ static struct btrfs_root *open_ctree_broken(int fd, const
char *device)
u64 features;
ret = btrfs_scan_one_device(fd, device, fs_devices,
- total_devs, BTRFS_SUPER_INFO_OFFSET);
+ total_devs, BTRFS_SUPER_INFO_OFFSET,
+ 0ull);
if (ret) {
fprintf(stderr, No valid Btrfs found on %s\n, device);
diff --git a/utils.c b/utils.c
index 15645c1..a2001de 100644
--- a/utils.c
+++ b/utils.c
@@ -922,7 +922,8 @@ int check_mounted_where(int fd, const char *file, char
*where, int size,
/* scan the initial device */
ret = btrfs_scan_one_device(fd, file, fs_devices_mnt,
- total_devs, BTRFS_SUPER_INFO_OFFSET);
+ total_devs, BTRFS_SUPER_INFO_OFFSET,
+ 0ull);
is_btrfs = (ret = 0);
/* scan other devices */
@@ -1126,7 +1127,8 @@ again:
fd = open(fullpath, O_RDONLY);
ret = btrfs_scan_one_device(fd, fullpath, tmp_devices,
num_devices,
- BTRFS_SUPER_INFO_OFFSET);
+ BTRFS_SUPER_INFO_OFFSET,
+ 0ull);
close(fd);
if (ret == 0 flags BTRFS_SCAN_REGISTER) {
@@ -1468,7 +1470,8 @@ scan_again:
fd = open(fullpath, O_RDONLY);
ret = btrfs_scan_one_device(fd, fullpath, tmp_devices,
num_devices,
- BTRFS_SUPER_INFO_OFFSET);
+ BTRFS_SUPER_INFO_OFFSET,
+ 0ull);
close(fd);
if (ret == 0 flags BTRFS_SCAN_REGISTER) {
btrfs_register_one_device(fullpath);
diff --git a/volumes.c b/volumes.c
index 1113cb5..a18b219 100644
--- a/volumes.c
+++ b/volumes.c
@@ -213,7 +213,7 @@ fail:
int btrfs_scan_one_device(int fd, const char *path,
struct btrfs_fs_devices **fs_devices_ret,
- u64 *total_devs, u64 super_offset)
+ u64 *total_devs, u64 super_offset, u64 flags)
{
struct btrfs_super_block *disk_super;
char *buf;
diff --git a/volumes.h b/volumes.h
index 911f788..f87aa5b 100644
--- a/volumes.h
+++ b/volumes.h
@@ -179,7 +179,7 @@ int btrfs_update_device(struct btrfs_trans_handle *trans,
struct btrfs_device *device);
int btrfs_scan_one_device(int fd, const char *path,
struct btrfs_fs_devices **fs_devices_ret,
- u64 *total_devs, u64 super_offset);
+ u64 *total_devs, u64 super_offset, u64 flags);
int btrfs_num_copies(struct btrfs_mapping_tree *map_tree, u64 logical, u64
len);
int btrfs_bootstrap_super_map(struct btrfs_mapping_tree *map_tree,
struct
[PATCH 3/5 v5] btrfs-progs: Introduce flag BTRFS_SCAN_BACKUP_SB for btrfs_read_dev_super
As of now btrfs_read_dev_super() reads the backup super block
by default and calling function has no control. However in the
following patch we would see that is undesirable.
So with the flag BTRFS_SCAN_BACKUP_SB the calling function
can now indicate if btrfs_read_dev_super should scan for
the backup SB when primary SB fails.
This patch just provides the frame-work, keeping all the logic
in the code same with or without this patch.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
disk-io.c | 10 +++---
disk-io.h | 3 ++-
find-root.c | 3 ++-
utils.h | 1 +
volumes.c | 4 +++-
5 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 6a03e9c..8d68c2e 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -880,7 +880,8 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, const
char *path,
fs_info-super_bytenr = sb_bytenr;
disk_super = fs_info-super_copy;
ret = btrfs_read_dev_super(fs_devices-latest_bdev,
- disk_super, sb_bytenr);
+ disk_super, sb_bytenr,
+ BTRFS_SCAN_BACKUP_SB);
if (ret) {
printk(No valid btrfs found\n);
goto out_devices;
@@ -1103,7 +1104,8 @@ struct btrfs_root *open_ctree_fd(int fp, const char
*path, u64 sb_bytenr,
return info-fs_root;
}
-int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 sb_bytenr)
+int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 sb_bytenr,
+ u64 flags)
{
u8 fsid[BTRFS_FSID_SIZE];
int fsid_is_initialized = 0;
@@ -1112,6 +1114,7 @@ int btrfs_read_dev_super(int fd, struct btrfs_super_block
*sb, u64 sb_bytenr)
int ret;
u64 transid = 0;
u64 bytenr;
+ int max;
if (sb_bytenr != BTRFS_SUPER_INFO_OFFSET) {
ret = pread64(fd, buf, sizeof(buf), sb_bytenr);
@@ -1126,7 +1129,8 @@ int btrfs_read_dev_super(int fd, struct btrfs_super_block
*sb, u64 sb_bytenr)
return 0;
}
- for (i = 0; i BTRFS_SUPER_MIRROR_MAX; i++) {
+ max = flags BTRFS_SCAN_BACKUP_SB ? BTRFS_SUPER_MIRROR_MAX : 1;
+ for (i = 0; i max; i++) {
bytenr = btrfs_sb_offset(i);
ret = pread64(fd, buf, sizeof(buf), bytenr);
if (ret sizeof(buf))
diff --git a/disk-io.h b/disk-io.h
index ff87958..40b7222 100644
--- a/disk-io.h
+++ b/disk-io.h
@@ -59,7 +59,8 @@ int close_ctree(struct btrfs_root *root);
int write_all_supers(struct btrfs_root *root);
int write_ctree_super(struct btrfs_trans_handle *trans,
struct btrfs_root *root);
-int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 sb_bytenr);
+int btrfs_read_dev_super(int fd, struct btrfs_super_block *sb, u64 sb_bytenr,
+ u64 flags);
int btrfs_map_bh_to_logical(struct btrfs_root *root, struct extent_buffer *bh,
u64 logical);
struct extent_buffer *btrfs_find_tree_block(struct btrfs_root *root,
diff --git a/find-root.c b/find-root.c
index 16920ed..0b08358 100644
--- a/find-root.c
+++ b/find-root.c
@@ -151,7 +151,8 @@ static struct btrfs_root *open_ctree_broken(int fd, const
char *device)
fs_info-super_bytenr = BTRFS_SUPER_INFO_OFFSET;
disk_super = fs_info-super_copy;
ret = btrfs_read_dev_super(fs_devices-latest_bdev,
- disk_super, BTRFS_SUPER_INFO_OFFSET);
+ disk_super, BTRFS_SUPER_INFO_OFFSET,
+ BTRFS_SCAN_BACKUP_SB);
if (ret) {
printk(No valid btrfs found\n);
goto out_devices;
diff --git a/utils.h b/utils.h
index 1de5143..ab22b02 100644
--- a/utils.h
+++ b/utils.h
@@ -24,6 +24,7 @@
#define BTRFS_MKFS_SYSTEM_GROUP_SIZE (4 * 1024 * 1024)
#define BTRFS_SCAN_REGISTER(1ULL 1)
+#define BTRFS_SCAN_BACKUP_SB (1ULL 2)
int make_btrfs(int fd, const char *device, const char *label,
u64 blocks[6], u64 num_bytes, u32 nodesize,
diff --git a/volumes.c b/volumes.c
index 3e52d06..1113cb5 100644
--- a/volumes.c
+++ b/volumes.c
@@ -29,6 +29,7 @@
#include transaction.h
#include print-tree.h
#include volumes.h
+#include utils.h
struct stripe {
struct btrfs_device *dev;
@@ -226,7 +227,8 @@ int btrfs_scan_one_device(int fd, const char *path,
goto error;
}
disk_super = (struct btrfs_super_block *)buf;
- ret = btrfs_read_dev_super(fd, disk_super, super_offset);
+ ret = btrfs_read_dev_super(fd, disk_super, super_offset,
+ BTRFS_SCAN_BACKUP_SB);
if (ret 0) {
ret = -EIO;
goto error_brelse;
--
1.8.1.227.g44fe835
--
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
Re: [PATCH 1/7] Btrfs: introduce a mutex lock for btrfs quota operations
Hi, Please ignore this patchset. V2 has been made and will be sent out soon! The main change is to use quota configurations on memory to speed up ioctls check. Thanks, Wang -- 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: [RFC] How to enable btrfs reserve block space from specific device?
On Wed, Mar 27, 2013 at 09:45:59AM +0800, Zhi Yong Wu wrote: HI, When i work on btrfs hot relocation feature, i hit one question about block reservation. btrfs hot relocation need to reserve block space from specific devices such as SSD, but current btrfs reserving code doesn't differentiate if block space is reserved from SSD or HDD. In order to make btrfs support this, I thought that we can introduce one new block group or flag, but this will maybe make large impact on current existing other functions. For this, does any guy have some better idea? thanks. Hi, Sorry for the late reply. I have a lot on my plate right now, so I haven't looked at your WIP code. However, based on my knowledge, I can tell you that block reservation problem is completely orthogonal to the way you choose to handle hot data storage. A separate block group is one way to do it, and probably the easiest one. Block groups - chunks is a 1:1 mapping, so, for now, it might make sense to have one giant block group spanning over the entire hot data device. OTOH, IIRC the original implementation from IBM just used the rotation flag to detect hot data devices. You have a lot of choices here, but, if you are planning on implementing mirrored/striped hot data devices in future, I'd definitely go with block groups, since that'll give you some of the infrastructure for that for free. Thanks, Ilya -- 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: No space left on device although df reports only 55% in use
On 03/27/2013 10:18 AM, Hugo Mills wrote: On Wed, Mar 27, 2013 at 12:28:23AM +0100, Clemens Eisserer wrote: I am using a btrfs loopback mounted file with lzo-compression on Linux-3.7.9, and I ran into No space left on device messages, although df reports only 55% of space is used: # touch testfile touch: cannot touch `testfile': No space left on device # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 32768000 17383924 14649172 55% /home/ce/anditest # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Your metadata is close to full -- we need quite a lot of working Almost 400MB are not sufficient to do simple touch? What is it doing? Cheers, Bernd -- 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: Kernel bug on mismatching generation_v2 in inode.c:835
What do you think; is this issue in the file system can be repaired with btrfsck? Or should I install a new, patched kernel on my partition somehow? -- 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 GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
On Tue, 3 Jul 2012 02:01:21 +0300, Sami Liedes wrote: Hi, I just got this oops on a computer running 3.4.2. A few minutes before I had started btrfs device scrub / and had a watcher process running btrfs scrub status / every 5 seconds. After a few gigabytes of scrubbing, I got this crash. The oops is transcribed from photos, so it may contain some errors. I tried to be careful, and double checked the backtrace. Sami general protection fault: [#1] SMP CPU 4 Modules linked in: tcp_diag inet_diag nfnetlink_log nfnetlink ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs reiserfs ext3 jbd ext2 ip6_tables ebtable_nat ebtables cn rfcomm bnep parport_pc ppdev lp parport tun cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative binfmt_misc fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc iptable_filter ipt_MASQUERADE ipt_REDIRECT iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables xfs ext4 jbd2 mbcache radeon drm_kms_helper ttm drm i2c_algo_bit loop kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm_oss snd_mixer_oss joydev snd_pcm acpi_cpufreq snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmi di ath3k snd_seq snd_seq_device snd_timer iTCO_wdt bluetooth eeepci_wmi asus_wmi sparse_keymap crc16 rfkill pcspkr psmouse coretemp serio_raw evdev mperf pci_hotplug i2c_i801 i2c_core processor button intel_agp snd mxm_wmi video wmi intel_gtt microcode soundcore sha256_generic dm_crypt dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq md_mod nbd btrfs libcrc32c zlib_deflate sd_mod crc_t10dif crc32c_intel ghash_cmulni_intel firewire_ohci r8196 firewire_core ahci aesni_intel libahci mii crc_itu_t aes_x86_64 libata aes_generic cryptd scsi_mod e1000e thermal fa n thermal_sys [last unloaded: scsi_wait_scan] Pid: 30863, comm: btrfs-endio-met Tainted: GW3.4.2 #1 System manufacturer System Product Name/P8P67 EVO RIP: 0010:[811e83bd] [811e83bd] memcpy+0xd/0x110 RSP: :88003174dba8 EFLAGS: 00010202 RAX: 88003174dc8f RBX: 0011 RCX: 0002 RDX: 0001 RSI: 00050803 RDI: 88003174dc8f RBP: 88003174dbf0 R08: 000a R09: R10: R11: R12: 88003174dca0 R13: 8800659f42b0 R14: 0048 R15: 0011 FS: () GS:88021ed0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0973c000 CR3: 000167ef3000 CR4: 000407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs-endio-met (pid: 30863, threadinfo 88003174c000, task 88006f818000) Stack: a026bd6b 8801960f5000 8003 1000 88003174dc58 03dd 88000ac13c60 88003174dc58 696f70203a61685f 88003174dc00 a026904d 88003174dcd0 Call Trace: [a026bd6b] ? read_extent_buffer+0xbb/0x110 [btrfs] [a026304d] btrfs_node_key+0x1d/0x20 [btrfs] [a02994e0] __readahead_hook.isra.5+0x3c0/0x420 [btrfs] [a029986f] btree_readahead_hook+0x1f/0x40 [btrfs] [a023f841] btree_readpage_end_io_hook+0x111/0x260 [btrfs] [a0267452] ? find_first_extent_bit_state+0x22/0x80 [btrfs] [a026809b] end_bio_extent_readpage+0xcb/0xa30 [btrfs] [a023ee61] ? end_workqueue_fn+0x31/0x50 [btrfs] [81158958] bio_endio+0x18/0x30 [a023ee6c] end_workqueue_fn+0x3c/0x50 [btrfs] [a0275857] worker_loop+0x157/0x560 [btrfs] [a0275700] ? btrfs_queue_worker+0x310/0x310 [btrfs] [81058e5e] kthread+0x8e/0xa0 [81418fe4] kernel_thread_helper+0x4/0x10 [81058dd0] ? flush_kthread_worker+0x70/0x70 [81418fe0] ? gs_change+0x13/0x13 Code: 4e 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 e8 eb fb ff ff eb e1 90 90 90 90 90 90 90... 8 4c 8b 56 10 4c RIP [811e83bd] memcpy+0xd/0x110 RSP 88003174dba8 Tonight my box had the same on a system running 3.7.10. Also with a Btrfs scrub running. general protection fault: [#1] SMP Modules linked in: xt_LOG xt_limit xt_multiport iptable_nat nf_nat_ipv4 nf_nat ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_mangle ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables bnep rfcomm bluetooth sp5100_tco edac_core edac_mce_amd k8temp i2c_piix4 kvm_amd kvm e1000e serio_raw mac_hid shpchp lp parport btrfs zlib_deflate libcrc32c raid10 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx
Re: Kernel bug on mismatching generation_v2 in inode.c:835
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Szőts Ákos wrote: What do you think; is this issue in the file system can be repaired with btrfsck? Or should I install a new, patched kernel on my partition somehow? Sorry I was flipping between your problem and somebody elses problem yesterday and I was having trouble restoring your file system from the image. Today I only have your problem and I'm almost done fixing this bug in the restore so I should have something for you today, hopefully before lunch. Thanks, Josef -- 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
Announce re-factor all current xfstests patches request
All xfstest developers, Thanks again for all your time in submitting and reviewing patches for xfstests. The latest patchset posted here: http://oss.sgi.com/archives/xfs/2013-03/msg00467.html requires all current patches to be re-factored. Sorry for the inconvenience. Thanks --Rich -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote: All xfstest developers, Thanks again for all your time in submitting and reviewing patches for xfstests. The latest patchset posted here: http://oss.sgi.com/archives/xfs/2013-03/msg00467.html requires all current patches to be re-factored. Given that we are now segregating patches into subdirectories, is it correct in the future tests should be named descriptively, instead of using 3 digit NNN numbers (which has been a major pain from a central assignment perspective)? If so, is there a suggested naming convention that is being recommended? Thanks for getting this change merged in!! - Ted -- 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: [RFC] How to enable btrfs reserve block space from specific device?
On Wed, Mar 27, 2013 at 7:34 PM, Ilya Dryomov idryo...@gmail.com wrote: On Wed, Mar 27, 2013 at 09:45:59AM +0800, Zhi Yong Wu wrote: HI, When i work on btrfs hot relocation feature, i hit one question about block reservation. btrfs hot relocation need to reserve block space from specific devices such as SSD, but current btrfs reserving code doesn't differentiate if block space is reserved from SSD or HDD. In order to make btrfs support this, I thought that we can introduce one new block group or flag, but this will maybe make large impact on current existing other functions. For this, does any guy have some better idea? thanks. Hi, Sorry for the late reply. I have a lot on my plate right now, so I No matter, thanks for you reply. it is definitely very helpful to me, thanks. haven't looked at your WIP code. However, based on my knowledge, I can tell you that block reservation problem is completely orthogonal to the way you choose to handle hot data storage. A separate block group is one way to do it, and probably the easiest one. Block groups - chunks is a 1:1 mapping, so, for now, it might make sense to have one giant Yes, bg:chunks is 1:1 mapping. block group spanning over the entire hot data device. OTOH, IIRC the If so,when hot relocation is enabled, will the other btrfs functions reserve block space only from HDD? In this case, will SSD seem to be only used as one cache? original implementation from IBM just used the rotation flag to detect yes, it determine if one device is SSD by one flag in request queue of that device. hot data devices. You have a lot of choices here, but, if you are planning on implementing mirrored/striped hot data devices in future, This is maybe next item, i will put it and meta relocation support in my TODO list. I'd definitely go with block groups, since that'll give you some of the infrastructure for that for free. Thanks, Ilya -- Regards, Zhi Yong Wu -- 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-progs: add quota-related info to usage messages
Extending usage messages with some info on the quota functionality:
- The -i option of subvol create and subvol snapshot was not
documented
- The -c option of qgroup limit is the default option
- The qouta rescan command is not yet implemented, while it should be
executed after enabling quota on a non-empty filesystem.
Signed-off-by: Koen De Wit koen.de@oracle.com
---
cmds-qgroup.c|3 ++-
cmds-quota.c |4
cmds-subvolume.c | 11 ---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/cmds-qgroup.c b/cmds-qgroup.c
index 275f00f..95aca9b 100644
--- a/cmds-qgroup.c
+++ b/cmds-qgroup.c
@@ -326,7 +326,8 @@ static const char * const cmd_qgroup_limit_usage[] = {
btrfs qgroup limit [options] size|none [qgroupid] path,
Limit the size of a subvolume quota group.,
,
--c limit amount of data after compression,
+-c limit amount of data after compression. This is the default,,
+ it is currently not possible to turn off this option.,
-e limit space exclusively assigned to this qgroup,
NULL
};
diff --git a/cmds-quota.c b/cmds-quota.c
index 8481514..71cd9f1 100644
--- a/cmds-quota.c
+++ b/cmds-quota.c
@@ -64,6 +64,9 @@ int quota_ctl(int cmd, int argc, char **argv)
static const char * const cmd_quota_enable_usage[] = {
btrfs quota enable path,
Enable subvolume quota support for a filesystem.,
+Any data already present on the filesystem will not count towards,
+the space usage numbers. It is recommended to enable quota for a,
+filesystem before writing any data to it.,
NULL
};
@@ -92,6 +95,7 @@ static int cmd_quota_disable(int argc, char **argv)
static const char * const cmd_quota_rescan_usage[] = {
btrfs quota rescan path,
Rescan the subvolume for a changed quota setting.,
+Not yet implemented.,
NULL
};
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 74e2130..b762470 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -61,10 +61,13 @@ static int test_isdir(char *path)
}
static const char * const cmd_subvol_create_usage[] = {
-btrfs subvolume create [dest/]name,
+btrfs subvolume create [-i qgroupid] [dest/]name,
Create a subvolume,
Create a subvolume name in dest. If dest is not given,
subvolume name will be created in the current directory.,
+,
+-i qgroupid add the newly created subvolume to a qgroup. This,
+ option can be given multiple times.,
NULL
};
@@ -480,12 +483,14 @@ out:
}
static const char * const cmd_snapshot_usage[] = {
-btrfs subvolume snapshot [-r] source [dest/]name,
+btrfs subvolume snapshot [-r] [-i qgroupid] source
[dest/]name,
Create a snapshot of the subvolume,
Create a writable/readonly snapshot of the subvolume source with,
the name name in the dest directory,
,
--r create a readonly snapshot,
+-r create a readonly snapshot,
+-i qgroupid add the newly created snapshot to a qgroup. This,
+ option can be given multiple times.,
NULL
};
--
1.7.2.5
--
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: Kernel bug on mismatching generation_v2 in inode.c:835
On Wed, Mar 27, 2013 at 05:51:32AM -0600, Szőts Ákos wrote: What do you think; is this issue in the file system can be repaired with btrfsck? Or should I install a new, patched kernel on my partition somehow? Ok I've successfully restored your image and I've reproduced your problem, I will let you know when I've fixed it. Thanks, Josef -- 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: Kernel bug on mismatching generation_v2 in inode.c:835
Oh, that's a very good news! Thank you very much :) -- 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: No space left on device although df reports only 55% in use
Hi Hugo, # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Your metadata is close to full -- we need quite a lot of working space to CoW into. You (probably) have the full disk allocated to chunks, and too much is allocated to data; not enough to metadata. You need o balance, with a filter for the unused data chunks. See the section in the FAQ on the wiki about full filesystems. (Sorry for not finding the link, I'm on a restricted connection right now) I'll re-run the test on a filesystem created with -M (metadata and normal data combined). As far as I understand it shouldn't run in the same problem. Almost 400MB are not sufficient to do simple touch? What is it doing? I have to admit that thought occurred to me too ;) Regards, Clemens -- 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-progs: add quota-related info to usage messages
Hello,
Extending usage messages with some info on the quota functionality:
- The -i option of subvol create and subvol snapshot was not documented
- The -c option of qgroup limit is the default option
- The qouta rescan command is not yet implemented, while it should be
executed after enabling quota on a non-empty filesystem.
Signed-off-by: Koen De Wit koen.de@oracle.com
These usage mesaages are really helpful now for users to try btrfs quota.
David, would you please pull this patch.
Thanks,
Wang
---
cmds-qgroup.c|3 ++-
cmds-quota.c |4
cmds-subvolume.c | 11 ---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/cmds-qgroup.c b/cmds-qgroup.c
index 275f00f..95aca9b 100644
--- a/cmds-qgroup.c
+++ b/cmds-qgroup.c
@@ -326,7 +326,8 @@ static const char * const cmd_qgroup_limit_usage[] = {
btrfs qgroup limit [options] size|none [qgroupid] path,
Limit the size of a subvolume quota group.,
,
--c limit amount of data after compression,
+-c limit amount of data after compression. This is the default,,
+ it is currently not possible to turn off this option.,
-e limit space exclusively assigned to this qgroup,
NULL
};
diff --git a/cmds-quota.c b/cmds-quota.c
index 8481514..71cd9f1 100644
--- a/cmds-quota.c
+++ b/cmds-quota.c
@@ -64,6 +64,9 @@ int quota_ctl(int cmd, int argc, char **argv)
static const char * const cmd_quota_enable_usage[] = {
btrfs quota enable path,
Enable subvolume quota support for a filesystem.,
+Any data already present on the filesystem will not count towards,
+the space usage numbers. It is recommended to enable quota for a,
+filesystem before writing any data to it.,
NULL
};
@@ -92,6 +95,7 @@ static int cmd_quota_disable(int argc, char **argv)
static const char * const cmd_quota_rescan_usage[] = {
btrfs quota rescan path,
Rescan the subvolume for a changed quota setting.,
+Not yet implemented.,
NULL
};
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 74e2130..b762470 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -61,10 +61,13 @@ static int test_isdir(char *path)
}
static const char * const cmd_subvol_create_usage[] = {
-btrfs subvolume create [dest/]name,
+btrfs subvolume create [-i qgroupid] [dest/]name,
Create a subvolume,
Create a subvolume name in dest. If dest is not given,
subvolume name will be created in the current directory.,
+,
+-i qgroupid add the newly created subvolume to a qgroup. This,
+ option can be given multiple times.,
NULL
};
@@ -480,12 +483,14 @@ out:
}
static const char * const cmd_snapshot_usage[] = {
-btrfs subvolume snapshot [-r] source [dest/]name,
+btrfs subvolume snapshot [-r] [-i qgroupid] source [dest/]name,
Create a snapshot of the subvolume,
Create a writable/readonly snapshot of the subvolume source with,
the name name in the dest directory,
,
--r create a readonly snapshot,
+-r create a readonly snapshot,
+-i qgroupid add the newly created snapshot to a qgroup. This,
+ option can be given multiple times.,
NULL
};
--
1.7.2.5
--
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] xfstests: make defrag test 222 generic
On 03/15/2013 11:05 AM, Eric Sandeen wrote: I think that's big enough change I should send a V2. and make a btrfs-special case in _defrag_dir. -Eric Ping Did I miss something, I know you are working on several things at once. :) Thanks --Rich -- 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: No space left on device although df reports only 55% in use
On Tue, Mar 26, 2013 at 05:28:23PM -0600, Clemens Eisserer wrote: Hi, I am using a btrfs loopback mounted file with lzo-compression on Linux-3.7.9, and I ran into No space left on device messages, although df reports only 55% of space is used: # touch testfile touch: cannot touch `testfile': No space left on device # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 32768000 17383924 14649172 55% /home/ce/anditest # btrfs filesystem df . Data: total=28.22GB, used=14.25GB System, DUP: total=8.00MB, used=12.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.50GB, used=1.16GB Metadata: total=8.00MB, used=0.00 Any ideas what is going wrong here? Can I see btrfs fi show and try using btrfs-next and see if the problem is already fixed. Thanks, Josef -- 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: Announce re-factor all current xfstests patches request
On 03/27/2013 08:46 AM, Theodore Ts'o wrote: On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote: All xfstest developers, Thanks again for all your time in submitting and reviewing patches for xfstests. The latest patchset posted here: http://oss.sgi.com/archives/xfs/2013-03/msg00467.html requires all current patches to be re-factored. Given that we are now segregating patches into subdirectories, is it correct in the future tests should be named descriptively, instead of using 3 digit NNN numbers (which has been a major pain from a central assignment perspective)? Yes If so, is there a suggested naming convention that is being recommended? Thanks for getting this change merged in!! - Ted I suggest: 1. They should also be descriptive of the test rather than a number. 2. All lowercase letters separated by _ i.e. something like tests/$FSTYP/break_my_filesystem Thanks --Rich -- 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
zlib vs lzo uncompress speed, ssd vs nossd
I just setup a new SSD with my laptop root filesystem, and at the time I though, eh, I'll just use zlib compression during the first copy, and then switch to lzo afterwards to maintain write speed when I'm using the laptop after the copy and reboot. Now, I rebooted with the new ssd and zlib compressed rootfs, and it seemed to boot slower than it did before with the same root files on btrfs lzo. My mount options are back to lzo: /dev/mapper/cryptroot / btrfs rw,noatime,compress=lzo,nossd,discard,space_cache 0 0 Is my feeling of slower boot wrong, or is zlib also noticeably slower than lzo to read and decompress? And separately, back a while ago, I read in multiple places that 'nossd' actually worked better than 'ssd'. This was over a year ago now. What's the current consensus on ssd and nosdd? Am I correct that it mostly affects how data is layed out at write time by btrfs? Should I go back to trying ssd instead of nossd? Thanks, Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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: Announce re-factor all current xfstests patches request
What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) Would you be open to changes which did this? I'd suggest sending the changes as a shell script to minimize the chances of patch conflicts. It will cause people to need to regenerate their patches, but that means now would be the time to do this, when everyone will need to be fixing up their outstanding changes anyway. :-) - Ted -- 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: Kernel bug on mismatching generation_v2 in inode.c:835
I ran two different versions of btrfsck on the partition. The first one was shipped with openSUSE 12.3, kernel 3.7. This is the original tool with which the partition was checked: http://paste.opensuse.org/74569620 The second one is from your tree (maybe it's newer): http://filebin.ca/bfbwJezYwCV/btrfsck-v2.txt Ákos -- 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: Kernel bug on mismatching generation_v2 in inode.c:835
On Wed, Mar 27, 2013 at 01:17:56PM -0600, Szőts Ákos wrote: I ran two different versions of btrfsck on the partition. The first one was shipped with openSUSE 12.3, kernel 3.7. This is the original tool with which the partition was checked: http://paste.opensuse.org/74569620 The second one is from your tree (maybe it's newer): http://filebin.ca/bfbwJezYwCV/btrfsck-v2.txt Ok so I'm still having some weird issues restoring your image and I wonder if they are because of the extent tree corruption. So it looks like you had some extent tree corruption and you are just unluckily getting hit because the free space inode is trying to write to an area that has csums but no extent. So can you do btrfsck --repair using the btrfsck from my tree (you may have to do it a few times to clear everything out) and then see if that fixes the problem for you? Thanks, Josef -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote: What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) It does seem like a good idea to help people map from descriptive names to their previous numeric file names. But do we want to bake it in to the file names forevermore? Would it be good enough to start the old tests with something like _was_test_nr 45 that spits out the old test number in the log? Just thinking out loud over here. - z -- 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-progs: make btrfs-image restore with a valid chunk tree V2
Previously btrfs-image would set a METADUMP flag and would make one big system
chunk to cover the entire file system in the super in order to get around the
unpleasant business of having to adjust the chunk tree. This meant that you
could use the progs stuff on a restored file system, which is great for testing
btrfsck and other such things. But we want to be able to run the tree log
replay on a file system that is not able to run the tree log replay. So in
order to do this we need to fixup the super's chunk array and the chunk tree
itself. This is pretty easy since we restore using the logical offsets of the
metadata, so we just have to set the chunk items to have 1 stripe and have the
stripes point at the primary device and then use the logical offset of the chunk
as the physical offset. With this patch I can restore a file system image that
had a tree log and mount the file system and have the log be replayed
successfully. This patch also gives you the -o option in case you want the old
restore way, in the case where we want to make sure the system chunks as they
were given to us are correct. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: fixed some bugs with restoring from a compressed image
btrfs-image.c| 311 --
man/btrfs-image.8.in |4 +
utils.c |4 +-
utils.h |2 +
4 files changed, 309 insertions(+), 12 deletions(-)
diff --git a/btrfs-image.c b/btrfs-image.c
index b39174b..861c3a3 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -110,10 +110,15 @@ struct mdrestore_struct {
struct list_head list;
size_t num_items;
+ u64 leafsize;
+ u64 devid;
+ u8 uuid[BTRFS_UUID_SIZE];
+ u8 fsid[BTRFS_FSID_SIZE];
int compress_method;
int done;
int error;
+ int old_restore;
};
static void csum_block(u8 *buf, size_t len)
@@ -254,7 +259,7 @@ static void meta_cluster_init(struct metadump_struct *md,
u64 start)
static int metadump_init(struct metadump_struct *md, struct btrfs_root *root,
FILE *out, int num_threads, int compress_level)
{
- int i, ret;
+ int i, ret = 0;
memset(md, 0, sizeof(*md));
pthread_cond_init(md-cond, NULL);
@@ -898,7 +903,7 @@ out:
return err ? err : ret;
}
-static void update_super(u8 *buffer)
+static void update_super_old(u8 *buffer)
{
struct btrfs_super_block *super = (struct btrfs_super_block *)buffer;
struct btrfs_chunk *chunk;
@@ -933,6 +938,221 @@ static void update_super(u8 *buffer)
csum_block(buffer, 4096);
}
+static int update_super(u8 *buffer)
+{
+ struct btrfs_super_block *super = (struct btrfs_super_block *)buffer;
+ struct btrfs_chunk *chunk;
+ struct btrfs_disk_key *disk_key;
+ struct btrfs_key key;
+ u32 new_array_size = 0;
+ u32 array_size;
+ u32 cur = 0;
+ u32 new_cur = 0;
+ u8 *ptr, *write_ptr;
+ int old_num_stripes;
+
+ write_ptr = ptr = super-sys_chunk_array;
+ array_size = btrfs_super_sys_array_size(super);
+
+ while (cur array_size) {
+ disk_key = (struct btrfs_disk_key *)ptr;
+ btrfs_disk_key_to_cpu(key, disk_key);
+
+ new_array_size += sizeof(*disk_key);
+ memmove(write_ptr, ptr, sizeof(*disk_key));
+
+ write_ptr += sizeof(*disk_key);
+ ptr += sizeof(*disk_key);
+ cur += sizeof(*disk_key);
+ new_cur += sizeof(*disk_key);
+
+ if (key.type == BTRFS_CHUNK_ITEM_KEY) {
+ chunk = (struct btrfs_chunk *)ptr;
+ old_num_stripes = btrfs_stack_chunk_num_stripes(chunk);
+ chunk = (struct btrfs_chunk *)write_ptr;
+
+ memmove(write_ptr, ptr, sizeof(*chunk));
+ btrfs_set_stack_chunk_num_stripes(chunk, 1);
+ btrfs_set_stack_chunk_sub_stripes(chunk, 0);
+ btrfs_set_stack_chunk_type(chunk,
+ BTRFS_BLOCK_GROUP_SYSTEM);
+ chunk-stripe.devid = super-dev_item.devid;
+ chunk-stripe.offset = cpu_to_le64(key.offset);
+ memcpy(chunk-stripe.dev_uuid, super-dev_item.uuid,
+ BTRFS_UUID_SIZE);
+ new_array_size += sizeof(*chunk);
+ new_cur += sizeof(*chunk);
+ } else {
+ fprintf(stderr, Bogus key in the sys chunk array
+ %d\n, key.type);
+ return -EIO;
+ }
+ write_ptr += sizeof(*chunk);
+ ptr += btrfs_chunk_item_size(old_num_stripes);
+ cur += btrfs_chunk_item_size(old_num_stripes);
+ }
+
+
Re: Announce re-factor all current xfstests patches request
Hey, On Wed, Mar 27, 2013 at 01:42:17PM -0700, Zach Brown wrote: On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote: What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) It does seem like a good idea to help people map from descriptive names to their previous numeric file names. But do we want to bake it in to the file names forevermore? Would it be good enough to start the old tests with something like _was_test_nr 45 that spits out the old test number in the log? Just thinking out loud over here. Maybe a text file containing the mapping would be sufficient. It's not as if it's going to grow. -Ben -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote: What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) When named test support is done, then we could do this. Would you be open to changes which did this? I'd suggest sending the changes as a shell script to minimize the chances of patch conflicts. It will cause people to need to regenerate their patches, but that means now would be the time to do this, when everyone will need to be fixing up their outstanding changes anyway. :-) There's more than just the rename of the file. group files have to change, there's the possibility that the group list and test list handling will need to be completely rewritten, the way test names are output will need work, the result summaries will need to be reformatted to be legible, etc. So it's not just a case of renaming a file - there's still quite a lot of infrastructure work needed before we can start using names rather then sequence numbers for tests. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 09:46:06AM -0400, Theodore Ts'o wrote: On Wed, Mar 27, 2013 at 08:23:07AM -0500, Rich Johnston wrote: All xfstest developers, Thanks again for all your time in submitting and reviewing patches for xfstests. The latest patchset posted here: http://oss.sgi.com/archives/xfs/2013-03/msg00467.html requires all current patches to be re-factored. Given that we are now segregating patches into subdirectories, is it correct in the future tests should be named descriptively, instead of using 3 digit NNN numbers (which has been a major pain from a central assignment perspective)? Support for named tests have not yet been added. From the check script: SUPPORTED_TESTS=[0-9][0-9][0-9] [0-9][0-9][0-9][0-9] Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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: zlib vs lzo uncompress speed, ssd vs nossd
On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN m...@merlins.org wrote: Is my feeling of slower boot wrong, or is zlib also noticeably slower than lzo to read and decompress? Lzo compression should be faster in every aspect than zlib, especially for reading. But having said that, btrfs won't recompress any existing files just because you switch your mount option from lzo to zlib. Only newly written files will be zlib, and btrfs will leave the lzo-compressed files alone unless they are re-written, or you expressly recompress them using the defrag tool. If you were to take a snapshot of your root partition, and reboot to the snapshot as the new root with zlib compression, you could make some side-by-side comparisons of boot time to clarify your impressions. -- 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: zlib vs lzo uncompress speed, ssd vs nossd
On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote: On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN m...@merlins.org wrote: Is my feeling of slower boot wrong, or is zlib also noticeably slower than lzo to read and decompress? Lzo compression should be faster in every aspect than zlib, especially for reading. But having said that, btrfs won't recompress any existing files just because you switch your mount option from lzo to zlib. Only newly written files will be zlib, and btrfs will leave the lzo-compressed files alone unless they are re-written, or you expressly recompress them using the defrag tool. That was my intent at the time, I thought that zlib decompression was about as fast as lzo, so it would have been good that most my files stayed compressed as zlib. Turns out I was wrong :) If you were to take a snapshot of your root partition, and reboot to the snapshot as the new root with zlib compression, you could make some side-by-side comparisons of boot time to clarify your impressions. Fair point. By that, you mean degrag all my files somehow (recompressing as lzo, and doubling the size of my rootfs)? Also, I was re-reading ssd vs nossd: https://btrfs.wiki.kernel.org/index.php/Mount_options isn't clear whether these are read/write ordering optimizations, or filesystem layout optimization (i.e. you'd have to recreate the entire FS, and rewrite everything). http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=1 says 'However, unless disabling the write cache for the drive, the SSD mode does not necessarily mean better performance. In fact, as our results are about to show, the quantitative disk performance can drop greatly in the SSD mode when the write cache remains enabled' But that's from 2009, so not very relevant to today. Do you happen to know more than me on this? Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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: zlib vs lzo uncompress speed, ssd vs nossd
On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote: Lzo compression should be faster in every aspect than zlib, especially for reading. Speaking of which, it would be awesome if there were a some chattr option to choose which encryption you'd like for a file or a subdirectory tree (compress this tree as much as you can, but use fast lzo for that tree). But I agree that would be lower on the priority list, and the chattr interface likely doesn't make that easy. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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: zlib vs lzo uncompress speed, ssd vs nossd
On Wed, Mar 27, 2013 at 4:22 PM, Marc MERLIN m...@merlins.org wrote: On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote: On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN m...@merlins.org wrote: Is my feeling of slower boot wrong, or is zlib also noticeably slower than lzo to read and decompress? Lzo compression should be faster in every aspect than zlib, especially for reading. But having said that, btrfs won't recompress any existing files just because you switch your mount option from lzo to zlib. Only newly written files will be zlib, and btrfs will leave the lzo-compressed files alone unless they are re-written, or you expressly recompress them using the defrag tool. That was my intent at the time, I thought that zlib decompression was about as fast as lzo, so it would have been good that most my files stayed compressed as zlib. Turns out I was wrong :) If you were to take a snapshot of your root partition, and reboot to the snapshot as the new root with zlib compression, you could make some side-by-side comparisons of boot time to clarify your impressions. Fair point. By that, you mean degrag all my files somehow (recompressing as lzo, and doubling the size of my rootfs)? Also, I was re-reading ssd vs nossd: https://btrfs.wiki.kernel.org/index.php/Mount_options isn't clear whether these are read/write ordering optimizations, or filesystem layout optimization (i.e. you'd have to recreate the entire FS, and rewrite everything). http://www.phoronix.com/scan.php?page=articleitem=btrfs_ssd_modenum=1 says 'However, unless disabling the write cache for the drive, the SSD mode does not necessarily mean better performance. In fact, as our results are about to show, the quantitative disk performance can drop greatly in the SSD mode when the write cache remains enabled' But that's from 2009, so not very relevant to today. Do you happen to know more than me on this? I'm sorry, I have no experience with the ssd mount option. -- 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: Kernel bug on mismatching generation_v2 in inode.c:835
I ran btrfsck three times and tried to restart the OS. After a generation_v2 resetting it booted and now it works! :) Thank you very much for your help! Two btrfsck run was needed for the complete cleanup, but interestingly the end statistics were a little bit different each time. Specifically, the values of - total fs tree bytes: 2285948928 - total extent tree bytes: 303124480 - btree space waste bytes: 742282214 lines varied with each run, even if there were no need of repairing. Ákos -- 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: Announce re-factor all current xfstests patches request
On Thu, Mar 28, 2013 at 07:54:07AM +1100, Dave Chinner wrote: Support for named tests have not yet been added. From the check script: SUPPORTED_TESTS=[0-9][0-9][0-9] [0-9][0-9][0-9][0-9] Ah, I thought support for named tests was there. For right now, though, if we have test ext4/123 and btrfs/123, that's OK and they are considered separate tests, right? Or do we still need to keep the numbers unique for now? - Ted -- 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 0/5 v5] access to backup-sb and btrfs' multipath aware
Any review comments on this ? pls. Thanks, Anand On 27/03/2013 18:07, Anand Jain wrote: We need a mechanism to tell when to use the backup super_block. To do this it needs a frame-work, and the patch #2 and #3 below provides the same without change in the logic. Its been found and posted to the list that check_mounted needs access to the backup-sb. so patch #3 adds flags parameter to the function btrfs_scan_one_device so that _only_ check_mounted can set the flag to access the backup-sb. patch#4 below is to enable and disable acecss to backup-sb for only certain threads v4-v5: Rebase with integration-20130321 and with my own changes (patch #1) Allow check_mounted thread-path to use backup-sb v3-v4: Fixed some warnings introduced by patch #3 below, sorry my mistake. v2-v3: Accepts David and Eric review, which would result in disabled access to backup-superblock by default. Dropped the patch [PATCH 3/3] btrfs-progs: use BTRFS_SCAN_BACKUP_SB flag in btrfs_scan_one_device Introduced a new patch [PATCH 3/3] btrfs-progs: disable using backup superblock by default v1-v2: Accepts Eric and Zach review. Separates fix into 3 patches for easy logical understanding Anand Jain (5): btrfs-progs: make btrfs dev scan multi path aware btrfs-progs: Introduce flag BTRFS_SCAN_REGISTER to replace run_ioctl btrfs-progs: Introduce flag BTRFS_SCAN_BACKUP_SB for btrfs_read_dev_super btrfs-progs: introduce passing flags to btrfs_scan_one_device btrfs-progs: disable using backup superblock by default cmds-device.c | 57 + cmds-replace.c | 2 +- disk-io.c | 15 ++- disk-io.h | 3 ++- find-root.c| 9 ++--- utils.c| 57 +++-- utils.h| 8 +--- volumes.c | 6 -- volumes.h | 2 +- 9 files changed, 109 insertions(+), 50 deletions(-) -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 01:42:17PM -0700, Zach Brown wrote: On Wed, Mar 27, 2013 at 03:05:12PM -0400, Theodore Ts'o wrote: What do you think about renaming the existing tests from NNN to NNN-descriptive-name? That way it will be easier for people who are trying to track regressions, since they can easily map from the new more descriptive name to the old test number for comparison purposes (i.e., to see whether a failure is a regression or not, etc.) It does seem like a good idea to help people map from descriptive names to their previous numeric file names. But do we want to bake it in to the file names forevermore? Would it be good enough to start the old tests with something like _was_test_nr 45 $ cd tests/generic $ ../../lsqa.pl -b 001 Random file copier to produce chains of identical files so the head and the tail can be diff'd at the end of each iteration. Exercises creat, write and unlink for a variety of directory sizes, and checks for data corruption. run [config] config has one line per file with filename and byte size, else use the default one below. $ ../../lsqa.pl -b 005 Test symlinks ELOOP $ Do we even really need to change them? Fix the lsqa.pl script be able to take a directory argument, and just use the script to get the description Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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: Announce re-factor all current xfstests patches request
On Wed, Mar 27, 2013 at 05:48:04PM -0400, Theodore Ts'o wrote: On Thu, Mar 28, 2013 at 07:54:07AM +1100, Dave Chinner wrote: Support for named tests have not yet been added. From the check script: SUPPORTED_TESTS=[0-9][0-9][0-9] [0-9][0-9][0-9][0-9] Ah, I thought support for named tests was there. For right now, though, if we have test ext4/123 and btrfs/123, that's OK and they are considered separate tests, right? Or do we still need to keep the numbers unique for now? Test numbers within a subdir are unique. So yes, ext4/123 and btrfs/123 are recognised as different tests. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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 and the steadily lit LED
On Wed, Mar 27, 2013 at 4:56 AM, Swâmi Petaramesh sw...@petaramesh.org wrote: After having received strong advice from the people in this list to upgrade my kernel to the latest one, I have installed 3.8.0-14-generic #24-Ubuntu SMP x86_64 on several (4) machines. In the hope of improving systems speed I had also removed all snapshots then defragged the FSes - the snapshots have been recreated since, as I use the excellent SuSE Snapper tool. But well, all 4 machines are still slow like hell. All of them are used for quite basic daily tasks - web browsing, email, typical LibreOffice tasks, nothing very mysterious there, no specific heavy DB work. All machines have 64-bits Linuxes (either Ubuntu 12.10 or 13.04ß), with decent amounts of RAM - 2 GB to 4 GB - and disks filled less than 75% With such a setup, I would expect any decent filesystem to deliver excellent performance. Still, all of my machines are slow like hell and I'm most of the time in mode « Working my patience while waiting for the HD LED to go off ». I haven't noticed any real-life noticeable improvement upgrading the kernels from 3.5.x to 3.8.x So I'm wondering... I must say after having used BTRFS for quite some time on many different desktop systems that this pretty much summaries my though of BTRFS used on a desktop system. I have been using it on my root filesystem for 5 consecutive systems and all of them were I/O bound most of the time after 2 months of normal usage with or *without* snapshots. Defragging or rebalancing doesn't help, growing leaf size helps push back the problem, but it eventually come back. The only way to get around the problem is to re-format the drive and restore from backups. I'm pretty sure I toasted 2 SSDs because of BTRFS, one in 4 months, the other in 6 months. 80 GB SSDs, I switched this system to NILFS2 for now, which isn't I/O bound and doesn't kill flash drives. A bigger system that I administer has 14 TB worth of data and has constant loads of 6 to 8 (4 CPUs), mostly because of I/O wait just because it unzips a file. This system never had a snapshot. On the system I'm writing, watching a YouTube video will hang one second every 30 seconds because flash player writes the video to /tmp. I submitted some backtrace but lost hope, I used kernel from 3.0 to 3.9-rc4 with the FS, features are great, it is great for a file server, but for desktop, it is really hard to use as root or /home because of this issue. Is there any data I can submit to help enhance performance on a desktop system? -- 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
