Corrupt filesystem after power failure

2011-02-10 Thread Anil Kumar
Hi,
I am using btrfs on my /home successfully for a while now.
After a power failure I am no longer able to mount it. I tried to use
btrfsck without any success.
The backup I have is about a month old, is there a way I can salvage my files?.
Full backtrace is at http://pastebin.com/4Re7tVFP
 I am aware of the danger of dataloss and wanted to change the filesystem.
Anyway it's too late now

Anil
--
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 use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
jer...@jeremysanders.net wrote:
 Olaf van der Spek wrote:

 On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman bell...@nsc.liu.se
 wrote:
 strncpy(args.name, source, BTRFS_PATH_NAME_MAX);
 args.name[BTRFS_PATH_NAME_MAX] = '\0';

 That's silly. Isn't there a sane safe variant of strcpy?

 There's strlcpy, but it's not in glibc because of possible truncation
 errors!

Then use a private wrapper.

-- 
Olaf
--
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 use safe string manipulation functions

2011-02-10 Thread Lars Wirzenius
On to, 2011-02-10 at 11:37 +, Jeremy Sanders wrote:
 There's strlcpy, but it's not in glibc because of possible truncation 
 errors!

snprintf is standard, and should be about as safe as it gets with the
glibc functions.

--
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: New btrfsck status

2011-02-10 Thread Chris Mason
Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500:
 Hey all,
 
 Over the last several months there have been many claims regarding the
 release of the rewritten btrfsck. Unfortunately, despite numerous
 claims that it will be released Real Soon Now(c), I have yet to see
 even a repository with preliminary code. Did I miss an announcement?
 There is something to be said for release early, release often. Is
 there a timeline for getting btrfsck into some sort of usable form?

Yes, but its still real soon now.  I've been at about 90% done since
Christmas.  It would have been out last week but I've been chasing a
debugging a very difficult corruption under load.

I finally found a race in btrfs causing the corruption and now I'm back
on fsck full time again.

-chris
--
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: New btrfsck status

2011-02-10 Thread Ben Gamari
On Thu, 10 Feb 2011 07:17:10 -0500, Chris Mason chris.ma...@oracle.com wrote:
 Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500:
  Is there a timeline for getting btrfsck into some sort of usable form?
 
 Yes, but its still real soon now.  I've been at about 90% done since
 Christmas.  It would have been out last week but I've been chasing a
 debugging a very difficult corruption under load.
 
 I finally found a race in btrfs causing the corruption and now I'm back
 on fsck full time again.
 
Glad to hear this. Thank you very much for your update. With respect to
the other thread (re: loose eSATA cable). I can keep the array around in
its current form if it would provide a good test case for btrfsck. That
being said, I'm really looking to recover some of the data from this
array if at all possible.

Cheers,

- 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: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:54 PM, Lars Wirzenius l...@liw.fi wrote:
 On to, 2011-02-10 at 11:37 +, Jeremy Sanders wrote:
 There's strlcpy, but it's not in glibc because of possible truncation
 errors!

 snprintf is standard, and should be about as safe as it gets with the
 glibc functions.

But snprintf is not like strlcpy.

Olaf
--
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: LOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)

2011-02-10 Thread Petr Uzel
On Tue, Jan 25, 2011 at 11:15:11AM +1100, Chris Samuel wrote:
 /*
  * CC'd to linux-kernel in case they have any feedback on this.
  *
  * Long thread, trying to work out why mkfs.btrfs failed to
  * make a filesystem on an encrypted loopback mount called
  * /dev/loop2. Cause turned out to be mkfs.btrfs calling
  * LOOP_GET_STATUS to find out if the block device was mounted
  * and getting a truncated device name back and so it later
  * fails when lstat() is called on the truncated device path.
  *
  * The long device name for the encrypted loopback mount was
  * because /dev/disk/by-id/$ID was used when Felix created it
  * to cope with devices moving around.
  */
 
 On 25/01/11 00:01, Felix Blanke wrote:
 
  you were talking about the LOOP_GET_STATUS function. I'm not
  quite sure where does it came from. Is it part of the kernel?
  Or does it come from the util-linux package?
 
 It's in the kernel, and there is both LOOP_GET_STATUS (old
 implementation) and LOOP_GET_STATUS64 (new implementation).
 
 They return structures called loop_info and loop_info64
 respectively and both are defined in include/linux/loop.h .
 
 Sadly in both cases the lengths of paths are defined to be
 LO_NAME_SIZE which is currently 64 and hence either
 implementation will cause the problematic:
 
 lstat(/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par,
 0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)
 
 I've CC'd this to the LKML in case they have any feedback on
 this apparent problem with the API.
 
Since 2.6.37, you can get full path to the backing file from sys:
cat /sys/block/loopX/loop/backing_file

See
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-07/msg10996.html


HTH,

Petr

--
Petr Uzel
IRC: ptr_uzl @ freenode


pgpYcrRI1mIyc.pgp
Description: PGP signature


Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Thomas Bellman
On 2011-02-10 13:27, Olaf van der Spek wrote:

 On Thu, Feb 10, 2011 at 12:54 PM, Lars Wirzenius l...@liw.fi wrote:

 snprintf is standard, and should be about as safe as it gets with the
 glibc functions.
 
 But snprintf is not like strlcpy.

It is indeed uglier to write 'snprintf(dst, size, %s, src)' instead of
'strlcpy(dst, src, size)', but both the effect and the return value should
be identical.

/Bellman
--
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: Corrupt filesystem after power failure

2011-02-10 Thread A. James Lewis

I'm far from an expert here, but perhaps you would be worth trying a
newer version of the BTRFS drivers, either via a newer kernel or
re-compiling a kernel with updated BTRFS patches.

I would think that the simplest quick test to see if this would help
you would be to get a snapshot from Ubuntu's daily build live CD iso,
and try mounting the filesystem with that... since it will have a recent
RC of 2.6.38 kernel which has a much more recent BTRFS version than the
2.6.34 which you are using.

http://cdimage.ubuntu.com/daily-live/current/

YMMV, but it's certainly something else to try.

James.


On Thu, 2011-02-10 at 22:29 +1100, Anil Kumar wrote:
 Hi,
 I am using btrfs on my /home successfully for a while now.
 After a power failure I am no longer able to mount it. I tried to use
 btrfsck without any success.
 The backup I have is about a month old, is there a way I can salvage my 
 files?.
 Full backtrace is at http://pastebin.com/4Re7tVFP
  I am aware of the danger of dataloss and wanted to change the filesystem.
 Anyway it's too late now
 
 Anil
 --
 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: Corrupt filesystem after power failure

2011-02-10 Thread Hugo Mills
On Thu, Feb 10, 2011 at 10:29:41PM +1100, Anil Kumar wrote:
 Full backtrace is at http://pastebin.com/4Re7tVFP

   Pastebins aren't archived. For posterity, here it is:

Feb 10 21:57:36 linux-wuce kernel: [  337.522818] Btrfs loaded
Feb 10 21:57:36 linux-wuce kernel: [  337.538044] device fsid 
d0485eeb5612434f-456b063393781ea9 devid 1 transid 131812 /dev/sda7
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.616905] [ cut here ]
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.616919] invalid opcode:  [#1] PREEMPT SMP
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.616926] last sysfs file: 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:32/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_now
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.617148] Stack:
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.617173] Call Trace:
 
Message from syslogd@linux-wuce at Feb 10 21:57:40 ...
 kernel:[  341.617866] Code: f4 52 96 e0 31 c0 48 81 c4 98 00 00 00 5b 5d 41 5c 
41 5d 41 5e 41 5f c3 b8 fe ff ff ff eb e7 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 
0f 0b 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 ec 28 01 00 00 48
Feb 10 21:57:40 linux-wuce kernel: [  341.616905] [ cut here 
]
Feb 10 21:57:40 linux-wuce kernel: [  341.616912] kernel BUG at 
/usr/src/packages/BUILD/kernel-desktop-2.6.34.7/linux-2.6.34/fs/btrfs/tree-log.c:813!
Feb 10 21:57:40 linux-wuce kernel: [  341.616919] invalid opcode:  [#1] 
PREEMPT SMP
Feb 10 21:57:40 linux-wuce kernel: [  341.616926] last sysfs file: 
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:32/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_now
Feb 10 21:57:40 linux-wuce kernel: [  341.616932] CPU 0
Feb 10 21:57:40 linux-wuce kernel: [  341.616935] Modules linked in: btrfs 
zlib_deflate crc32c libcrc32c arc4 ecb ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG 
xt_limit af_packet vmsync vmblock snd_pcm_oss snd_mixer_oss snd_seq 
snd_seq_device edd vboxdrv ip6t_REJECT nf_conntrack_ipv6 ip6table_raw 
xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter cpufreq_conservative 
cpufreq_userspace cpufreq_powersave acpi_cpufreq mperf ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables 
ip6table_filter ip6_tables x_tables vfat fat fuse loop dm_mod 
snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec 
snd_hwdep snd_pcm snd_timer snd soundcore sr_mod iTCO_wdt usb_storage 
r8192se_pci atl1c iTCO_vendor_support cdrom sg pcspkr acer_wmi snd_page_alloc 
i2c_i801 battery ac joydev rfkill wmi ext4 jbd2 crc16 sd_mod i915 ahci libata 
drm_kms_helper scsi_mod drm i2c_algo_bit video intel_agp button fan thermal 
processor thermal_sys [last unloaded: preloadtrace]
Feb 10 21:57:40 linux-wuce kernel: [  341.617054]
Feb 10 21:57:40 linux-wuce kernel: [  341.617060] Pid: 7628, comm: mount Not 
tainted 2.6.34.7-0.7-desktop #1 E7214  /E7214  
Feb 10 21:57:40 linux-wuce kernel: [  341.617065] RIP: 
0010:[a07d5eb3]  [a07d5eb3] add_inode_ref+0x4a3/0x4b0 
[btrfs]
Feb 10 21:57:40 linux-wuce kernel: [  341.617094] RSP: 0018:8800b09af8b8  
EFLAGS: 00010246
Feb 10 21:57:40 linux-wuce kernel: [  341.617098] RAX:  RBX: 
0097 RCX: 
Feb 10 21:57:40 linux-wuce kernel: [  341.617103] RDX: 0002 RSI: 
880074374820 RDI: 8800b0d9a280
Feb 10 21:57:40 linux-wuce kernel: [  341.617107] RBP: 0002 R08: 
 R09: ff6dc8d155c6ee03
Feb 10 21:57:40 linux-wuce kernel: [  341.617112] R10:  R11: 
 R12: 8800b09afb78
Feb 10 21:57:40 linux-wuce kernel: [  341.617116] R13: 88007215db50 R14: 
0009 R15: 8800b09af9d8
Feb 10 21:57:40 linux-wuce kernel: [  341.617121] FS:  7fb2eddb07e0() 
GS:880001e0() knlGS:
Feb 10 21:57:40 linux-wuce kernel: [  341.617126] CS:  0010 DS:  ES:  
CR0: 8005003b
Feb 10 21:57:40 linux-wuce kernel: [  341.617131] CR2: 7f01f58e5020 CR3: 
b1d7f000 CR4: 06f0
Feb 10 21:57:40 linux-wuce kernel: [  341.617135] DR0:  DR1: 
 DR2: 
Feb 10 21:57:40 linux-wuce kernel: [  341.617140] DR3:  DR6: 
0ff0 DR7: 0400
Feb 10 21:57:40 linux-wuce kernel: [  341.617145] Process mount (pid: 7628, 
threadinfo 8800b09ae000, task 8800b1dca540)
Feb 10 21:57:40 linux-wuce kernel: [  341.617148] Stack:
Feb 10 21:57:40 linux-wuce kernel: [  341.617151]   
 a079a930 88007215db50
Feb 10 21:57:40 linux-wuce kernel: [  341.617158] 0 8800b17fe000 
88007e035eb0 8800b5991000 0009
Feb 10 21:57:40 linux-wuce kernel: [  341.617165] 0 8800b09af9b8 
880074374d78 88007215db50 0004
Feb 10 

Re: [PATCH] Btrfs-progs use safe string manipulation functions

2011-02-10 Thread Eduardo Silva
On Thu, 2011-02-10 at 12:39 +0100, Olaf van der Spek wrote:
 On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
 jer...@jeremysanders.net wrote:
  Olaf van der Spek wrote:
 
  On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman bell...@nsc.liu.se
  wrote:
  strncpy(args.name, source, BTRFS_PATH_NAME_MAX);
  args.name[BTRFS_PATH_NAME_MAX] = '\0';
 
  That's silly. Isn't there a sane safe variant of strcpy?
 
  There's strlcpy, but it's not in glibc because of possible truncation
  errors!
 
 Then use a private wrapper.
 

Here's the new patch:


[PATCH] Add safe string manipulation functions

Deprecate direct use of strcpy(3)
The following string manipulation function has been added:

   - string_copy() : wrapper of strcpy(3)
   - string_ncopy(): wrapper of strncpy(3)

both function compose safe NULL terminated strings.


I check that the code most of the time raise an error if the path is too
long, so the new wrappers should be ok...

best, 

Eduardo Silva
 
From 6e551f4d9482a438beb336c4ec3a54735a15b76c Mon Sep 17 00:00:00 2001
From: Eduardo Silva eduardo.si...@oracle.com
Date: Thu, 10 Feb 2011 10:25:15 -0300
Subject: [PATCH] Add safe string manipulation functions

Deprecate direct use of strcpy(3)
The following string manipulation function has been added:

   - string_copy() : wrapper of strcpy(3)
   - string_ncopy(): wrapper of strncpy(3)

both function compose safe NULL terminated strings.

Signed-off-by: Eduardo Silva eduardo.si...@oracle.com
---
 btrfs-list.c |4 ++--
 btrfs-vol.c  |2 +-
 btrfs.c  |3 ++-
 btrfs_cmds.c |   14 +++---
 btrfsctl.c   |2 +-
 convert.c|4 ++--
 utils.c  |   38 --
 utils.h  |5 +
 8 files changed, 52 insertions(+), 20 deletions(-)

diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..ede51a4 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -291,7 +291,7 @@ static int lookup_ino_path(int fd, struct root_info *ri)
 			perror(malloc failed);
 			exit(1);
 		}
-		strcpy(ri-path, args.name);
+		string_copy(ri-path, args.name);
 		strcat(ri-path, ri-name);
 	} else {
 		/* we're at the root of ref_tree */
@@ -448,7 +448,7 @@ char *build_name(char *dirid, char *name)
 	full = malloc(strlen(dirid) + strlen(name) + 1);
 	if (!full)
 		return NULL;
-	strcpy(full, dirid);
+	string_copy(full, dirid);
 	strcat(full, name);
 	return full;
 }
diff --git a/btrfs-vol.c b/btrfs-vol.c
index 4ed799d..60361f6 100644
--- a/btrfs-vol.c
+++ b/btrfs-vol.c
@@ -151,7 +151,7 @@ int main(int ac, char **av)
 	}
 	fd = dirfd(dirstream);
 	if (device)
-		strcpy(args.name, device);
+		string_copy(args.name, device);
 	else
 		args.name[0] = '\0';
 
diff --git a/btrfs.c b/btrfs.c
index 46314cf..ddf4960 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -21,6 +21,7 @@
 
 #include kerncompat.h
 #include btrfs_cmds.h
+#include utils.h
 #include version.h
 
 typedef int (*CommandFunction)(int argc, char **argv);
@@ -241,7 +242,7 @@ static int prepare_args(int *ac, char ***av, char *prgname, struct Command *cmd
 	for(i=0; i  *ac ; i++ )
 		ret[i+1] = (*av)[i];
 
-	strcpy(newname, prgname);
+	string_copy(newname, prgname);
 	strcat(newname,  );
 	strcat(newname, cmd-verb);
 
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..f4be8c2 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -375,7 +375,7 @@ int do_clone(int argc, char **argv)
 	printf(Create a snapshot of '%s' in '%s/%s'\n,
 	   subvol, dstdir, newname);
 	args.fd = fd;
-	strcpy(args.name, newname);
+	string_ncopy(args.name, newname, BTRFS_PATH_NAME_MAX);
 	res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
 
 	close(fd);
@@ -436,7 +436,7 @@ int do_delete_subvolume(int argc, char **argv)
 	}
 
 	printf(Delete subvolume '%s/%s'\n, dname, vname);
-	strcpy(args.name, vname);
+	string_ncopy(args.name, vname, BTRFS_PATH_NAME_MAX);
 	res = ioctl(fd, BTRFS_IOC_SNAP_DESTROY, args);
 
 	close(fd);
@@ -490,7 +490,7 @@ int do_create_subvol(int argc, char **argv)
 	}
 
 	printf(Create subvolume '%s/%s'\n, dstdir, newname);
-	strcpy(args.name, newname);
+	string_ncopy(args.name, newname, BTRFS_PATH_NAME_MAX);
 	res = ioctl(fddst, BTRFS_IOC_SUBVOL_CREATE, args);
 
 	close(fddst);
@@ -553,7 +553,7 @@ int do_scan(int argc, char **argv)
 
 		printf(Scanning for Btrfs filesystems in '%s'\n, argv[i]);
 
-		strcpy(args.name, argv[i]);
+		string_ncopy(args.name, argv[i], BTRFS_PATH_NAME_MAX);
 		/*
 		 * FIXME: which are the error code returned by this ioctl ?
 		 * it seems that is impossible to understand if there no is
@@ -593,7 +593,7 @@ int do_resize(int argc, char **argv)
 	}
 
 	printf(Resize '%s' of '%s'\n, path, amount);
-	strcpy(args.name, amount);
+	string_ncopy(args.name, amount, BTRFS_VOL_NAME_MAX);
 	res = ioctl(fd, BTRFS_IOC_RESIZE, args);
 	close(fd);
 	if( res  0 ){
@@ -736,7 +736,7 @@ int do_add_volume(int nargs, char **args)
 		}
 		close(devfd);
 
-		strcpy(ioctl_args.name, args[i]);
+		string_ncopy(ioctl_args.name, args[i], BTRFS_PATH_NAME_MAX);
 		res = ioctl(fdmnt, 

Re: [PATCH] Btrfs-progs new btrfs_error() macro to deprecate fprintf(stderr, ...)

2011-02-10 Thread Hubert Kario
On Thursday, February 10, 2011 15:54:55 Eduardo Silva wrote:
 Hi,
 
 This patch add a new macro called btrfs_error(...) which deprecate the
 use of fprintf(stderr, ...)
 
 regards,
 
 Eduardo

Sorry, but I don't see a reason for such change. IMHO it only makes the code 
_less_ readable.

Regards,
-- 
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
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 use safe string manipulation functions

2011-02-10 Thread Olaf van der Spek
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
jer...@jeremysanders.net wrote:
 Of course C++ strings would be much better... :-)

Yeah, why isn't C++ being used?

Olaf
--
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: mkfs.btrfs - error checking /dev/sda5 mount status

2011-02-10 Thread Goffredo Baroncelli
On 02/09/2011 09:12 PM, Lubos Kolouch wrote:
 Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100:
 
 On 02/08/2011 10:26 PM, Lubos Kolouch wrote:
 Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100:

 On 02/08/2011 07:57 AM, Lubos Kolouch wrote:
 Hi,

 I'm hitting this issue - sda5 is a normal device, nothing to do with
 loop, encryption etc.

 # mkfs.btrfs /dev/sda5

 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! -
 see http://btrfs.wiki.kernel.org before using

 error checking /dev/sda5 mount status

 Is there something I can do to resolve this?

 Some months ago I posted a patch [*] which allows to create a
 filesystem even if an integrity tests fail.
 Anyway it would be interesting understand why mkfs.btrfs fails. It is
 possible to have a strace of the command ?


 here ... http://paste.pocoo.org/show/334638/ but it is not in chroot,
 it is in normal system

 Lubos


 Hi Lubos,

 Could you post also the output of cat /proc/mounts command and the
 output of btrfs filesystem show command. I cannot understand what
 should be the problem.
 
 Hi Goffredo,
 
 Sure,
 # cat /proc/mounts
 
 rootfs / rootfs rw 0 0
 /dev/root / btrfs rw,noatime,compress,ssd 0 0
 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
 rc-svcdir /lib/rc/init.d tmpfs 
 rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0
 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 
 0 0
 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
 udev /dev devtmpfs 
 rw,nosuid,relatime,size=10240k,nr_inodes=217934,mode=755 0 0
 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
 none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
 none /dev/shm tmpfs rw,relatime 0 0
 /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0
 none /var/tmp/portage tmpfs rw,relatime 0 0
 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc 
 rw,nosuid,nodev,noexec,relatime 0 0
 /dev/mapper/_dev_sda6 /home btrfs rw,noatime,compress,ssd 0 0
 
 # btrfs filesystem show
 
 Label: none  uuid: fd070c17-e98b-4b50-9fa8-3453482aafa2
   Total devices 1 FS bytes used 5.51GB
   devid1 size 18.64GB used 10.79GB path /dev/sda2
 
 Label: none  uuid: bf9a1b00-f8bd-44d3-b140-10eea088a60e
   Total devices 1 FS bytes used 6.73GB
   devid1 size 19.54GB used 19.54GB path /dev/sda5
 
 Label: none  uuid: ae0ba016-1945-4e7a-9fb4-e9311d199727
   Total devices 1 FS bytes used 57.50GB
   devid1 size 78.91GB used 78.91GB path /dev/dm-0
 
 # mkfs.btrfs /dev/sda5
 
 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL
 WARNING! - see http://btrfs.wiki.kernel.org before using
 
 error checking /dev/sda5 mount status
 
 Also, I can mount it no problem - strange, isn't it


Ok, I think to have track down the problem. To me it seems a bug in
mkfs.btrfs.

The first thing that should be highlighted is that you are trying to
format an already btrfs formatted device. In this there is not anything
wrong.

However, before formatting a device mkfs.btrfs performs some sanity
check. It checks if the device is already mounted, scanning /proc/mounts.

In a normal case (the device which will be formatted doesn't contain a
btrfs filesystem), mkfs.btrfs is smart enough to don't check device
which are in /proc/mounts bat doesn't exist (like /dev/root).

Instead when the device which will be formatted already contains a btrfs
filesystem, mkfs.btrfs performs a different checks. In fact it considers
also the case of a multi-device based btrfs filesystem. However in this
case it doesn't skip a not existent device but it raises an error. I
think that this is a bug.

As workaround I suggest the following: make a link between the real root
device and /dev/root.

It should be sufficient to format the device.



 Lubos
 
 --
 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: mkfs.btrfs - error checking /dev/sda5 mount status

2011-02-10 Thread Lubos Kolouch
Goffredo Baroncelli, Thu, 10 Feb 2011 19:24:57 +0100:

 On 02/09/2011 09:12 PM, Lubos Kolouch wrote:
 Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100:
 
 On 02/08/2011 10:26 PM, Lubos Kolouch wrote:
 Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100:

 On 02/08/2011 07:57 AM, Lubos Kolouch wrote:
 Hi,

 I'm hitting this issue - sda5 is a normal device, nothing to do
 with loop, encryption etc.

 # mkfs.btrfs /dev/sda5

 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! -
 see http://btrfs.wiki.kernel.org before using

 error checking /dev/sda5 mount status

 Is there something I can do to resolve this?

 Some months ago I posted a patch [*] which allows to create a
 filesystem even if an integrity tests fail. Anyway it would be
 interesting understand why mkfs.btrfs fails. It is possible to have
 a strace of the command ?


 here ... http://paste.pocoo.org/show/334638/ but it is not in chroot,
 it is in normal system

 Lubos


 Hi Lubos,

 Could you post also the output of cat /proc/mounts command and the
 output of btrfs filesystem show command. I cannot understand what
 should be the problem.
 
 Hi Goffredo,
 
 Sure,
 # cat /proc/mounts
 
 rootfs / rootfs rw 0 0
 /dev/root / btrfs rw,noatime,compress,ssd 0 0 proc /proc proc
 rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib/rc/init.d tmpfs
 rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys
 sysfs rw,nosuid,nodev,noexec,relatime 0 0 securityfs
 /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
 udev /dev devtmpfs
 rw,nosuid,relatime,size=10240k,nr_inodes=217934,mode=755 0 0 fusectl
 /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /dev/pts devpts
 rw,relatime,mode=600,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0
 0
 /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0 none
 /var/tmp/portage tmpfs rw,relatime 0 0 binfmt_misc
 /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0
 0
 /dev/mapper/_dev_sda6 /home btrfs rw,noatime,compress,ssd 0 0
 
 # btrfs filesystem show
 
 Label: none  uuid: fd070c17-e98b-4b50-9fa8-3453482aafa2
  Total devices 1 FS bytes used 5.51GB
  devid1 size 18.64GB used 10.79GB path /dev/sda2
 
 Label: none  uuid: bf9a1b00-f8bd-44d3-b140-10eea088a60e
  Total devices 1 FS bytes used 6.73GB
  devid1 size 19.54GB used 19.54GB path /dev/sda5
 
 Label: none  uuid: ae0ba016-1945-4e7a-9fb4-e9311d199727
  Total devices 1 FS bytes used 57.50GB devid1 size 78.91GB used
  78.91GB path /dev/dm-0
 
 # mkfs.btrfs /dev/sda5
 
 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see
 http://btrfs.wiki.kernel.org before using
 
 error checking /dev/sda5 mount status
 
 Also, I can mount it no problem - strange, isn't it
 
 
 Ok, I think to have track down the problem. To me it seems a bug in
 mkfs.btrfs.
 
 The first thing that should be highlighted is that you are trying to
 format an already btrfs formatted device. In this there is not anything
 wrong.
 
 However, before formatting a device mkfs.btrfs performs some sanity
 check. It checks if the device is already mounted, scanning
 /proc/mounts.
 
 In a normal case (the device which will be formatted doesn't contain a
 btrfs filesystem), mkfs.btrfs is smart enough to don't check device
 which are in /proc/mounts bat doesn't exist (like /dev/root).
 
 Instead when the device which will be formatted already contains a btrfs
 filesystem, mkfs.btrfs performs a different checks. In fact it considers
 also the case of a multi-device based btrfs filesystem. However in this
 case it doesn't skip a not existent device but it raises an error. I
 think that this is a bug.
 
 As workaround I suggest the following: make a link between the real root
 device and /dev/root.
 
 It should be sufficient to format the device.
 

Hello - you are right...

# ln -s /dev/sda2 /dev/root

# mkfs.btrfs /dev/sda5

WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/sda5
nodesize 4096 leafsize 4096 sectorsize 4096 size 19.54GB
Btrfs v0.19-35-g1b444cd-dirty


Lubos

--
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 use safe string manipulation functions

2011-02-10 Thread Goffredo Baroncelli
On 02/10/2011 02:29 PM, Eduardo Silva wrote:
 On Thu, 2011-02-10 at 12:39 +0100, Olaf van der Spek wrote:
 On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
 jer...@jeremysanders.net wrote:
 Olaf van der Spek wrote:

 On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman bell...@nsc.liu.se
 wrote:
 strncpy(args.name, source, BTRFS_PATH_NAME_MAX);
 args.name[BTRFS_PATH_NAME_MAX] = '\0';

 That's silly. Isn't there a sane safe variant of strcpy?

 There's strlcpy, but it's not in glibc because of possible truncation
 errors!

 Then use a private wrapper.

 
 Here's the new patch:
 
 
 [PATCH] Add safe string manipulation functions
 
 Deprecate direct use of strcpy(3)
 The following string manipulation function has been added:
 
- string_copy() : wrapper of strcpy(3)
- string_ncopy(): wrapper of strncpy(3)
 
 both function compose safe NULL terminated strings.
 
 
 I check that the code most of the time raise an error if the path is too
 long, so the new wrappers should be ok...
 
 best, 
 
 Eduardo Silva
  
[...]
+char *string_copy(char *dest, const char *src)
+{
+   if (!dest || !src) {
+   fprintf(stderr, ERROR: invalid string_copy() parameters);
+   exit(EXIT_FAILURE);
+   }
+
+   memset(dest, '\0', sizeof(dest));

What is the purpose of the line above ?  sizeof(dest) is a const value
(typically 4 or 8) !

I agree with Olaf that string_copy() is usefulness.

I suggest you to improve the check of the string length before the copy
(not in the copy function), and raising an error when the length of the
string is too long.

Regards
G.Baroncelli
--
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 v2]Btrfs: pwrite blocked when writing from the mmaped buffer of the same page

2011-02-10 Thread Zhong, Xin
Hi,

Could you paste the output of sysrq+t here? Thanks!

-Original Message-
From: Johannes Hirte [mailto:johannes.hi...@fem.tu-ilmenau.de] 
Sent: Wednesday, February 02, 2011 7:35 AM
To: Zhong, Xin
Cc: Maria Wikström; linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2]Btrfs: pwrite blocked when writing from the mmaped 
buffer of the same page

On Friday 28 January 2011 04:53:24 Zhong, Xin wrote:
 Could you describe the steps to recreate it?
 It will be a great help for me to look further. Thanks!

It's a little strange. I have to systems with btrfs, both Gentoo-based. One is 
affected by this bug the other is not. On the affected system it is enough to 
do 
a 'emerge dev-libs/libgcrypt' that should normaly compile and install 
libgcrypt. The emerge command is part of portage, the package management of 
Gentoo. 
The strace output looks similar to the one from Maria:

open(/home/tmp/portage/dev-libs/libgcrypt-1.4.6/.ipc_in, O_RDONLY|
O_NONBLOCK|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFIFO|0770, st_size=0, ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0xbff5f678) = -1 EINVAL (Invalid argument)
open(/dev/ptmx, O_RDWR)   = 5
ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(5, TIOCGPTN, [2]) = 0
stat64(/dev/pts/2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
getuid32()  = 0
ioctl(5, TIOCSPTLCK, [0])   = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(5, TIOCGPTN, [2]) = 0
stat64(/dev/pts/2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
open(/dev/pts/2, O_RDWR|O_NOCTTY) = 6
ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(6, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(6, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B38400 -opost 
isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
stat64(/root/.terminfo, 0xbff5e790)   = -1 ENOENT (No such file or directory)
stat64(/etc/terminfo, {st_mode=S_IFDIR|0755, st_size=14, ...}) = 0
access(/etc/terminfo/x/xterm, R_OK)   = 0
open(/etc/terminfo/x/xterm, O_RDONLY|O_LARGEFILE) = 7
read(7, \32\0010\0\0\17\0\235\1l\5xterm|xterm terminal..., 4097) = 3258
close(7)= 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=40, ws_col=207, ws_xpixel=0, ws_ypixel=0}) = 0
access(/usr/local/sbin/stty, X_OK)= -1 ENOENT (No such file or directory)
access(/usr/local/bin/stty, X_OK) = -1 ENOENT (No such file or directory)
access(/usr/sbin/stty, X_OK)  = -1 ENOENT (No such file or directory)
access(/usr/bin/stty, X_OK)   = -1 ENOENT (No such file or directory)
access(/sbin/stty, X_OK)  = -1 ENOENT (No such file or directory)
access(/bin/stty, X_OK)   = 0
stat64(/bin/stty, {st_mode=S_IFREG|0755, st_size=58836, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xb753d728) = 2752
waitpid(2752, [{WIFEXITED(s)  WEXITSTATUS(s) == 0}], 0) = 2752
--- SIGCHLD (Child exited) @ 0 (0) ---
fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
fstat64(5, {st_mode=S_IFCHR|0666, st_rdev=makedev(5, 2), ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B38400 -opost isig icanon echo ...}) = 0
open(/home/tmp/portage/dev-libs/libgcrypt-1.4.6/temp/build.log, O_WRONLY|
O_CREAT|O_APPEND|O_LARGEFILE, 0666) = 7
fstat64(7, {st_mode=S_IFREG|0660, st_size=480, ...}) = 0
_llseek(7, 0, [480], SEEK_END)  = 0
ioctl(7, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
0xbff5fad8) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(7, {st_mode=S_IFREG|0660, st_size=480, ...}) = 0
_llseek(7, 0, [480], SEEK_CUR)  = 0
stat64(/home/tmp/portage/dev-libs/libgcrypt-1.4.6/temp/build.log, 
{st_mode=S_IFREG|0660, st_size=480, ...}) = 0
dup(1)  = 8
fstat64(8, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
ioctl(8, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or