Re: Boot speed/mount time regression with 3.4.0-rc2
On Fri, Apr 13, 2012 at 3:47 PM, Josef Bacik wrote: > On Fri, Apr 13, 2012 at 02:26:19PM +0200, Ahmet Inan wrote: >> On Fri, Apr 13, 2012 at 1:22 PM, Ahmet Inan >> wrote: >> > On Fri, Apr 13, 2012 at 8:49 AM, cwillu wrote: >> >>> dmesg and fstab attached as requested. >> >> >> >> Need dmesg after you've hit alt-sysrq-w a couple times during the slow >> >> period. >> > >> > here. >> > >> > i guess i should also increase dmesg history size next time. >> > other than the slow boot, everything seems normal after 10-20minutes. >> > >> > fyi: the space_cache option is not really helping with those >> > twenty computers. the one thing i observed is, that sometimes >> > they reboot fast and only to reboot slow again after that. >> >> sorry for spaming the list with my dmesg files, >> please tell me, how i could do better. >> >> here a more complete dmesg. > > Hrm so you are getting blocked task warnings just trying to mount the > filesystem, so either your disk is really really really slow or there's > something bigger going on. Let me think about this some and I'll get back to > you. Josef, i finally found out something: btrfs in kernel => fast boot btrfs as module => very slow boot and here see the results: http://aam.mathematik.uni-freiburg.de/IAM/homepages/ainan/bootchart_btrfs_in_kernel.png this is much, much better! I dont understand why btrfs as a module performs that bad on rotating disk. On SSD i had no issues and also i never used space_cache before. Im going to deploy the new kernel on our systems next week with btrfs in-kernel and come back with the results. Ahmet -- 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
bug?
Hello, today my laptop crashed with the following output. Installed is Archlinux with btrfs on a SSD. Is it btrfs related? Thanks, Thomas Apr 21 13:01:01 localhost anacron[3307]: Anacron started on 2012-04-21 Apr 21 13:01:01 localhost anacron[3307]: Will run job `cron.daily' in 48 min. Apr 21 13:01:01 localhost anacron[3307]: Jobs will be executed sequentially Apr 21 13:21:01 localhost -- MARK -- Apr 21 13:41:01 localhost -- MARK -- Apr 21 13:49:01 localhost anacron[3307]: Job `cron.daily' started Apr 21 13:49:14 localhost kernel: [23420.297861] general protection fault: [#1] PREEMPT SMP Apr 21 13:49:14 localhost kernel: [23420.297976] CPU 1 Apr 21 13:49:14 localhost kernel: [23420.298007] Modules linked in: nls_cp437 vfat fat usb_storage uas aes_x86_64 cryptd aes_generic fuse ext4 jbd2 mbcache crc16 joydev arc4 dell_wmi sparse_keymap i915 snd_hda_codec_idt iwl3945 dell_laptop dcdbas iwl_legacy mac80211 snd_hda_intel i2c_algo_bit snd_hda_codec drm_kms_helper evdev snd_hwdep snd_pcm drm serio_raw psmouse pcspkr tg3 snd_page_alloc cfg80211 snd_timer i2c_i801 iTCO_wdt iTCO_vendor_support snd i2c_core libphy rfkill soundcore intel_agp intel_gtt wmi thermal button battery video processor ac btrfs crc32c libcrc32c zlib_deflate sr_mod cdrom sd_mod pata_acpi ata_generic ata_piix libata scsi_mod ehci_hcd uhci_hcd usbcore usb_common Apr 21 13:49:14 localhost kernel: [23420.299233] Apr 21 13:49:14 localhost kernel: [23420.299262] Pid: 11172, comm: updatedb Not tainted 3.2.11-1-ARCH #1 Dell Inc. Latitude D530 /0HP728 Apr 21 13:49:14 localhost kernel: [23420.299410] RIP: 0010:[] [] btrfs_getattr+0x3d/0x90 [btrfs] Apr 21 13:49:14 localhost kernel: [23420.299560] RSP: 0018:880077765e38 EFLAGS: 00010206 Apr 21 13:49:14 localhost kernel: [23420.299630] RAX: 41d7fffe RBX: 8800bf6c1550 RCX: 000c Apr 21 13:49:14 localhost kernel: [23420.299717] RDX: 880077765f00 RSI: 880077765f00 RDI: 8800bf6c1550 Apr 21 13:49:14 localhost kernel: [23420.299804] RBP: 880077765e58 R08: 81173373 R09: 8800ba43bcf8 Apr 21 13:49:14 localhost kernel: [23420.299891] R10: 8800ba43bcc0 R11: 0005 R12: 880077765f00 Apr 21 13:49:14 localhost kernel: [23420.299978] R13: 1000 R14: 880077765f00 R15: 01e54c50 Apr 21 13:49:14 localhost kernel: [23420.300067] FS: 7f3e42b8f700() GS:88011fd0() knlGS: Apr 21 13:49:14 localhost kernel: [23420.300168] CS: 0010 DS: ES: CR0: 80050033 Apr 21 13:49:14 localhost kernel: [23420.300240] CR2: 01e71ffc CR3: 58685000 CR4: 06e0 Apr 21 13:49:14 localhost kernel: [23420.300327] DR0: DR1: DR2: Apr 21 13:49:14 localhost kernel: [23420.300414] DR3: DR6: 0ff0 DR7: 0400 Apr 21 13:49:14 localhost kernel: [23420.300502] Process updatedb (pid: 11172, threadinfo 880077764000, task 88008a8023a0) Apr 21 13:49:14 localhost kernel: [23420.300603] Stack: Apr 21 13:49:14 localhost kernel: [23420.300635] 880077765f68 8800ba43bcc0 88011707bd00 8800bf6c1550 Apr 21 13:49:14 localhost kernel: [23420.300753] 880077765e98 8116c51e 880077765f00 01e38319 Apr 21 13:49:14 localhost kernel: [23420.300869] 880077765f00 01e38319 7fffd821ca18 Apr 21 13:49:14 localhost kernel: [23420.300985] Call Trace: Apr 21 13:49:14 localhost kernel: [23420.301001] [] vfs_getattr+0x4e/0x80 Apr 21 13:49:14 localhost kernel: [23420.301001] [] vfs_fstatat+0x4e/0x70 Apr 21 13:49:14 localhost kernel: [23420.301001] [] vfs_lstat+0x1e/0x20 Apr 21 13:49:14 localhost kernel: [23420.301001] [] sys_newlstat+0x1a/0x40 Apr 21 13:49:14 localhost kernel: [23420.301001] [] system_call_fastpath+0x16/0x1b Apr 21 13:49:14 localhost kernel: [23420.301001] Code: 6d f8 66 66 66 66 90 48 8b 5e 30 48 89 d6 49 89 d4 48 8b 43 28 48 89 df 44 8b 68 18 e8 5d b2 fe e0 48 8b 83 60 fe ff ff 48 89 df <8b> 80 00 04 00 00 49 c7 44 24 58 00 10 00 00 41 89 44 24 08 e8 Apr 21 13:49:14 localhost kernel: [23420.301001] RIP [] btrfs_getattr+0x3d/0x90 [btrfs] Apr 21 13:49:14 localhost kernel: [23420.301001] RSP Apr 21 13:49:14 localhost anacron[3307]: Job `cron.daily' terminated (exit status: 1) (mailing output) Apr 21 13:49:14 localhost anacron[3307]: Can't find sendmail at /usr/sbin/sendmail, not mailing output Apr 21 13:49:14 localhost anacron[3307]: Normal exit (1 job run) Apr 21 13:49:14 localhost kernel: [23420.365362] ---[ end trace 27dae2a049083cf1 ]--- -- 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
Accidental use of mkfs.btrfs -L ... recoverable?
In all haste i accidentally used mkfs.btrfs -L to label a partition with data on it. Is there any way to recover the contents other then something like testdisk to scan the whole drive? brgds Andreas -- 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 v4] btrfs: fix early abort in 'remount'
From: Sergei Trofimovich
[ Typical case of btrfs rootfs without initramfs: ]
When trying to remount 'ro' -> 'rw' filesystem
we get early abort from 'btrfs_remount()' due to
first unconditional 'goto':
> if (fs_info->fs_devices->rw_devices == 0)
> ret = -EACCES;
> goto restore; /* misindented */
Thus nothing like 'btrfs_super_log_root()' or
'btrfs_cleanup_fs_roots()' gets called and all
new options passed to remount are reverted and
'mount -o remount' does not return an error.
The regression is introduced by commit 49b25e05409.
Remounting 'rw' -> 'rw' is fine.
Cc: Chris Mason
Acked-by: Jeff Mahoney
Reviewed-by: Josef Bacik
Reviewed-by: Sergey V.
Signed-off-by: Sergei Trofimovich
---
v1->v2: fixed indentation of 'if (cond) {' suggested by Liu Bo
v2->v3: added 'Reviewed-by'
v3->v4: added Jeff's 'Acked-by'; enhanced changelog
fs/btrfs/super.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8d5d380..2f28fc0 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1148,13 +1148,15 @@ static int btrfs_remount(struct super_block *sb, int
*flags, char *data)
if (ret)
goto restore;
} else {
- if (fs_info->fs_devices->rw_devices == 0)
+ if (fs_info->fs_devices->rw_devices == 0) {
ret = -EACCES;
goto restore;
+ }
- if (btrfs_super_log_root(fs_info->super_copy) != 0)
+ if (btrfs_super_log_root(fs_info->super_copy) != 0) {
ret = -EINVAL;
goto restore;
+ }
ret = btrfs_cleanup_fs_roots(fs_info);
if (ret)
--
1.7.8.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
[PATCHv3 3/4] avoid several strncpy-induced buffer overruns
From: Jim Meyering
* restore.c (main): Ensure strncpy-copied dir_name is NUL-terminated.
* btrfsctl.c (main): Likewise, for a command-line argument.
* utils.c (multiple functions): Likewise.
* btrfs-list.c (add_root): Likewise.
* btrfslabel.c (change_label_unmounted): Likewise.
* cmds-device.c (cmd_add_dev, cmd_rm_dev, cmd_scan_dev): Likewise.
* cmds-filesystem.c (cmd_resize): Likewise.
* cmds-subvolume.c (cmd_subvol_create, cmd_subvol_delete, cmd_snapshot):
Likewise.
Reviewed-by: Josef Bacik
---
btrfs-list.c |2 ++
btrfsctl.c|5 +++--
btrfslabel.c |1 +
cmds-device.c |3 +++
cmds-filesystem.c |1 +
cmds-subvolume.c |3 +++
restore.c |3 ++-
utils.c | 13 ++---
8 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 5f4a9be..35e6139 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -183,6 +183,8 @@ static int add_root(struct root_lookup *root_lookup,
ri->root_id = root_id;
ri->ref_tree = ref_tree;
strncpy(ri->name, name, name_len);
+ if (name_len > 0)
+ ri->name[name_len-1] = 0;
ret = tree_insert(&root_lookup->root, root_id, ref_tree, &ri->rb_node);
if (ret) {
diff --git a/btrfsctl.c b/btrfsctl.c
index d45e2a7..518684c 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -241,9 +241,10 @@ int main(int ac, char **av)
fd = open_file_or_dir(fname);
}
- if (name)
+ if (name) {
strncpy(args.name, name, BTRFS_PATH_NAME_MAX + 1);
- else
+args.name[BTRFS_PATH_NAME_MAX] = 0;
+ } else
args.name[0] = '\0';
if (command == BTRFS_IOC_SNAP_CREATE) {
diff --git a/btrfslabel.c b/btrfslabel.c
index c9f4684..da694e1 100644
--- a/btrfslabel.c
+++ b/btrfslabel.c
@@ -58,6 +58,7 @@ static void change_label_unmounted(char *dev, char *nLabel)
trans = btrfs_start_transaction(root, 1);
strncpy(root->fs_info->super_copy.label, nLabel, BTRFS_LABEL_SIZE);
+ root->fs_info->super_copy.label[BTRFS_LABEL_SIZE-1] = 0;
btrfs_commit_transaction(trans, root);
/* Now we close it since we are done. */
diff --git a/cmds-device.c b/cmds-device.c
index db625a6..771856b 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -117,6 +117,7 @@ static int cmd_add_dev(int argc, char **argv)
close(devfd);
strncpy(ioctl_args.name, argv[i], BTRFS_PATH_NAME_MAX);
+ ioctl_args.name[BTRFS_PATH_NAME_MAX-1] = 0;
res = ioctl(fdmnt, BTRFS_IOC_ADD_DEV, &ioctl_args);
e = errno;
if(res<0){
@@ -161,6 +162,7 @@ static int cmd_rm_dev(int argc, char **argv)
int res;
strncpy(arg.name, argv[i], BTRFS_PATH_NAME_MAX);
+ arg.name[BTRFS_PATH_NAME_MAX-1] = 0;
res = ioctl(fdmnt, BTRFS_IOC_RM_DEV, &arg);
e = errno;
if(res<0){
@@ -226,6 +228,7 @@ static int cmd_scan_dev(int argc, char **argv)
printf("Scanning for Btrfs filesystems in '%s'\n", argv[i]);
strncpy(args.name, argv[i], BTRFS_PATH_NAME_MAX);
+ args.name[BTRFS_PATH_NAME_MAX-1] = 0;
/*
* FIXME: which are the error code returned by this ioctl ?
* it seems that is impossible to understand if there no is
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index 1f53d1c..ea9e788 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -489,6 +489,7 @@ static int cmd_resize(int argc, char **argv)
printf("Resize '%s' of '%s'\n", path, amount);
strncpy(args.name, amount, BTRFS_PATH_NAME_MAX);
+ args.name[BTRFS_PATH_NAME_MAX-1] = 0;
res = ioctl(fd, BTRFS_IOC_RESIZE, &args);
e = errno;
close(fd);
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 950fa8f..a01c830 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -111,6 +111,7 @@ static int cmd_subvol_create(int argc, char **argv)
printf("Create subvolume '%s/%s'\n", dstdir, newname);
strncpy(args.name, newname, BTRFS_PATH_NAME_MAX);
+ args.name[BTRFS_PATH_NAME_MAX-1] = 0;
res = ioctl(fddst, BTRFS_IOC_SUBVOL_CREATE, &args);
e = errno;
@@ -202,6 +203,7 @@ static int cmd_subvol_delete(int argc, char **argv)
printf("Delete subvolume '%s/%s'\n", dname, vname);
strncpy(args.name, vname, BTRFS_PATH_NAME_MAX);
+ args.name[BTRFS_PATH_NAME_MAX-1] = 0;
res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, &args);
e = errno;
@@ -378,6 +380,7 @@ static int cmd_snapshot(int argc, char **argv)
args.fd = fd;
strncpy(args.name, newname, BTRFS_SUBVOL_NAME_MAX);
+ args.name[BTRFS_SUBVOL_NAME_MAX-1] = 0;
res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_V2, &args);
e = errno;
diff --git a/restore.c b/restore.c
index 2674832..d1ac542 100644
--- a/restor
[PATCHv3 2/4] restore: don't corrupt stack for a zero-length command-line argument
From: Jim Meyering
Given a zero-length directory name, the trailing-slash removal
code would test dir_name[-1], and if it were found to be a slash,
would set it to '\0'.
Reviewed-by: Josef Bacik
---
restore.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/restore.c b/restore.c
index 250c9d3..2674832 100644
--- a/restore.c
+++ b/restore.c
@@ -849,11 +849,9 @@ int main(int argc, char **argv)
strncpy(dir_name, argv[optind + 1], 128);
/* Strip the trailing / on the dir name */
- while (1) {
- len = strlen(dir_name);
- if (dir_name[len - 1] != '/')
- break;
- dir_name[len - 1] = '\0';
+ len = strlen(dir_name);
+ while (len && dir_name[--len] == '/') {
+ dir_name[len] = '\0';
}
if (find_dir) {
--
1.7.10.228.g81f95
--
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
[PATCHv3 4/4] mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
From: Jim Meyering
* mkfs.c (parse_size): ./mkfs.btrfs -A '' would read and possibly
write the byte before beginning of strdup'd heap buffer. All other
size-accepting options were similarly affected.
Reviewed-by: Josef Bacik
---
mkfs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mkfs.c b/mkfs.c
index 03239fb..4aff2fd 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -63,7 +63,7 @@ static u64 parse_size(char *s)
s = strdup(s);
- if (!isdigit(s[len - 1])) {
+ if (len && !isdigit(s[len - 1])) {
c = tolower(s[len - 1]);
switch (c) {
case 'g':
--
1.7.10.228.g81f95
--
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
[PATCHv3 1/4] mkfs: use strdup in place of strlen,malloc,strcpy sequence
From: Jim Meyering * mkfs.c (traverse_directory): No semantic change. Reviewed-by: Josef Bacik --- mkfs.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mkfs.c b/mkfs.c index c531ef2..03239fb 100644 --- a/mkfs.c +++ b/mkfs.c @@ -911,8 +911,7 @@ static int traverse_directory(struct btrfs_trans_handle *trans, /* Add list for source directory */ dir_entry = malloc(sizeof(struct directory_name_entry)); dir_entry->dir_name = dir_name; - dir_entry->path = malloc(strlen(dir_name) + 1); - strcpy(dir_entry->path, dir_name); + dir_entry->path = strdup(dir_name); parent_inum = highest_inum + BTRFS_FIRST_FREE_OBJECTID; dir_entry->inum = parent_inum; -- 1.7.10.228.g81f95 -- 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: minor buffer-overrun fixes (v3)
[I realized I'd need this v3 as I was falling asleep last night. ] Same net effect as v2, but bisectable, now that the fix - args.name[BTRFS_PATH_NAME_MAX-1] = 0; + args.name[BTRFS_SUBVOL_NAME_MAX-1] = 0; is applied to 3/4, rather than to 4/4. [PATCHv3 1/4] mkfs: use strdup in place of strlen,malloc,strcpy [PATCHv3 2/4] restore: don't corrupt stack for a zero-length [PATCHv3 3/4] avoid several strncpy-induced buffer overruns [PATCHv3 4/4] mkfs: avoid heap-buffer-read-underrun for zero-length -- 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
