Re: inquiry on btrfs send/receive

2012-06-05 Thread Alexander Block
On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas alex.bolshoy.bt...@gmail.com wrote: Yes, I also noticed that sometimes transid gets bumped up, but there is no actual change. So let's say you identify that a particular part of the tree is not shared anymore, and, say, eventually you get to a

[PATCH 4/8] btrfs: Use printk_get_level and printk_skip_level, add __printf, fix fallout

2012-06-05 Thread Joe Perches
Use the generic printk_get_level function to search a message for a kern_level. Add __printf to verify format and arguments. Fix a few messages that had mismatches in format and arguments. Add #ifdef CONFIG_PRINTK blocks to shrink the object size a bit when not using printk. Signed-off-by: Joe

[PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
KERN_LEVEL currently takes up 3 bytes. Shrink the kernel size by using an ASCII SOH and then the level byte. Remove the need for KERN_CONT. Convert directly embedded uses of . to KERN_LEVEL Joe Perches (8): printk: Add generic functions to find KERN_LEVEL headers printk: Add kern_levels.h to

Re: Help with data recovering

2012-06-05 Thread Martin Steigerwald
Am Montag, 4. Juni 2012 schrieb Hugo Mills: On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote: I run through all potential tree roots. It gave me everytime messages like these: parent transid verify failed on 3405159735296 wanted 9096 found 5263 parent transid verify failed

Re: Help with data recovering

2012-06-05 Thread Martin Steigerwald
Am Dienstag, 5. Juni 2012 schrieb Martin Steigerwald: Am Montag, 4. Juni 2012 schrieb Hugo Mills: On Mon, Jun 04, 2012 at 12:24:05PM -0400, Maxim Mikheev wrote: I run through all potential tree roots. It gave me everytime messages like these: parent transid verify failed on

Re: Help with data recovering

2012-06-05 Thread Martin Steigerwald
Am Montag, 4. Juni 2012 schrieb Maxim Mikheev: --super works but my root tree 2 has many errors too. What can I do next? Have a data recovery company try to physically recover the bad harddisk to a good one and then try to mount BTRFS again and hope that your previous attempts to repair the

Re: [btrfs-progs] [bug][patch] Leaking file handle in scrub_fs_info()

2012-06-05 Thread Hugo Mills
Hi, Goffredo, I'm trying to do a new integration branch, and the patch inline in the text is corrupt (plus it has a massively verbose commit message): Applying: Leaking file handle in scrub_fs_info() fatal: corrupt patch at line 74 Patch failed at 0001 Leaking file handle in

Re: Help with data recovering

2012-06-05 Thread Helmut Hullen
Hallo, Martin, Du meintest am 05.06.12: --super works but my root tree 2 has many errors too. What can I do next? Have a data recovery company try to physically recover the bad harddisk to a good one About 1 year ago I asked Kroll-Ontrack. They told me they couldn't (yet) recover btrfs.

Re: Recovering a file from a snapshot without duplicating its blocks (--reflink across devs?)

2012-06-05 Thread Marc MERLIN
On Tue, Jun 05, 2012 at 01:42:50PM +1000, Chris Samuel wrote: On 05/06/12 13:01, Marc MERLIN wrote: First I though, I sure would be nice if I could take btrfs to reference the same blocks from the snapshot to my current image. But, --reflink failed across devices nodes, so I was forced to

Re: [systemd-devel] systemd-udevd: excessive I/O usage

2012-06-05 Thread Diego Calleja
[resend, for some reason kmail formatted the previous message with html] On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió: Result: boot from ext4 takes less than 15 seconds, while boot from btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data file is not

delete disk proceedure

2012-06-05 Thread Jim
Good morning btrfs list, I had written about 2 weeks ago about using extra btrfs space in an nfs file system setup. Nfs seems to export the files but the mounts don't work on older machines without btrfs kernels. So I am down to deleting several drives from btrfs to setup a standard raid 1

Re: [systemd-devel] systemd-udevd: excessive I/O usage

2012-06-05 Thread Alexander E. Patrakov
2012/6/5 Diego Calleja dieg...@gmail.com: [resend, for some reason kmail formatted the previous message with html] On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió: Result: boot from ext4 takes less than 15 seconds, while boot from btrfs takes 9 minutes (or 5 minutes if I

Re: delete disk proceedure

2012-06-05 Thread Hugo Mills
On Tue, Jun 05, 2012 at 10:38:11AM -0400, Jim wrote: Good morning btrfs list, I had written about 2 weeks ago about using extra btrfs space in an nfs file system setup. Nfs seems to export the files but the mounts don't work on older machines without btrfs kernels. The mounts don't work

PATCH: btrfs defrag ioctl, override extent count and size checks compression enabled.

2012-06-05 Thread Andrew Mahone
I noticed a few days ago that btrfs fi defrag -cXXX can not be used to compress files unless they are fragmented. The attached patch passes the compression flag to should_defrag_range, where it disables the adjacent-extent and extent size checks if set. The inline/sparse extent check is not

Re: delete disk proceedure

2012-06-05 Thread Helmut Hullen
Hallo, Jim, Du meintest am 05.06.12: /dev/sda 11T 4.9T 6.0T 46% /btrfs [root@advanced ~]# btrfs fi show failed to read /dev/sr0 Label: none uuid: c21f1221-a224-4ba4-92e5-cdea0fa6d0f9 Total devices 12 FS bytes used 4.76TB devid6 size 930.99GB used

Re: delete disk proceedure

2012-06-05 Thread Jim
[sorry for the resend, signature again] I am waiting for a window (later tonight) when I can try mounting the btrfs export. Am I reading you guys correctly, that you think I should be deleting drives from the array? Or is this a just in case? Thanks. Jim Maloney On 06/05/2012 01:04 PM,

Re: delete disk proceedure

2012-06-05 Thread Hugo Mills
On Tue, Jun 05, 2012 at 01:12:17PM -0400, Jim wrote: [sorry for the resend, signature again] I am waiting for a window (later tonight) when I can try mounting the btrfs export. Am I reading you guys correctly, that you think I should be deleting drives from the array? Or is this a just in

Re: [systemd-devel] systemd-udevd: excessive I/O usage

2012-06-05 Thread Kok, Auke-jan H
On Mon, Jun 4, 2012 at 8:50 PM, Alexander E. Patrakov patra...@gmail.com wrote: 2012/6/5 Kok, Auke-jan H auke-jan.h@intel.com wrote on systemd-devel list: It seems your system is taking well into 15+ seconds before btrfs is actually *ready* on your system, which seems to be the main

Re: [btrfs-progs] [bug][patch V2] Leaking file handle in scrub_fs_info()

2012-06-05 Thread Goffredo Baroncelli
Hi Hugo, I was not able to reproduce your error with my repository: I pulled it without problem. However, enclosed you can find the patch (as attachment) with the Jan suggestions about the spaces. You can pull the patch also from my repo ( same branch: fd-leaking). Moreover I inserted the patch

Re: delete disk proceedure

2012-06-05 Thread Helmut Hullen
Hallo, Hugo, Du meintest am 05.06.12: [...] And you can't use the console from where you have started the balance command. Therefore I wrap this command: echo 'btrfs filesystem balance /btrfs' | at now ... or just put it into the background with btrfs bal start /mountpoint . You

[PATCH 1/2] Btrfs: use rcu to protect device-name

2012-06-05 Thread Josef Bacik
Al pointed out that we can just toss out the old name on a device and add a new one arbitrarily, so anybody who uses device-name in printk could possibly use free'd memory. Instead of adding locking around all of this he suggested doing it with RCU, so I've introduced a struct rcu_string that

[PATCH 2/2] Btrfs: implement -show_devname

2012-06-05 Thread Josef Bacik
Because btrfs can remove the device that was mounted we need to have a -show_devname so that in this case we can print out some other device in the file system to /proc/mount. We keep track of what device we called mount() with so that we can print out the correct one if it is still available,

New btrfs-progs integration branch

2012-06-05 Thread Hugo Mills
, there's minimal testing involved here, but it does at least compile on my system(*). The branch is fetchable with git from: http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605 And viewable in human-readable form at: http://git.darksatanic.net/cgi/gitweb.cgi?p

Re: [btrfs-progs] [bug][patch V2] Leaking file handle in scrub_fs_info()

2012-06-05 Thread Goffredo Baroncelli
Hi Hugo, On 06/05/2012 08:19 PM, Hugo Mills wrote: On Tue, Jun 05, 2012 at 07:26:34PM +0200, Goffredo Baroncelli wrote: Hi Hugo, I was not able to reproduce your error with my repository: I pulled it without problem. Well, I'd have normally written it off as a corrupt local repo at

Re: inquiry on btrfs send/receive

2012-06-05 Thread Alex Lyakas
On Tue, Jun 5, 2012 at 12:16 PM, Alexander Block abloc...@googlemail.com wrote: On Mon, Jun 4, 2012 at 7:33 PM, Alex Lyakas alex.bolshoy.bt...@gmail.com wrote: Yes, I also noticed that sometimes transid gets bumped up, but there is no actual change. So let's say you identify that a

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Tue, 5 Jun 2012 02:46:29 -0700 Joe Perches j...@perches.com wrote: KERN_LEVEL currently takes up 3 bytes. Shrink the kernel size by using an ASCII SOH and then the level byte. Remove the need for KERN_CONT. Convert directly embedded uses of . to KERN_LEVEL What an epic patchset. I guess

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Tue, Jun 5, 2012 at 11:28 PM, Andrew Morton a...@linux-foundation.org wrote: On Tue,  5 Jun 2012 02:46:29 -0700 Joe Perches j...@perches.com wrote: KERN_LEVEL currently takes up 3 bytes. Shrink the kernel size by using an ASCII SOH and then the level byte. Remove the need for KERN_CONT.

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: Unfortunately the n thing is part of the kernel ABI: echo 4foo /dev/kmsg Which works the same way it did before. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: Unfortunately the n thing is part of the kernel ABI: echo 4foo /dev/kmsg Which works the same way it did before. I didn't say it didn't. What I did say

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Tue, 2012-06-05 at 15:17 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 15:11:43 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: Unfortunately the n thing is part of the kernel ABI: echo 4foo /dev/kmsg Which works the

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: devkmsg_writev() does weird and wonderful things with facilities/levels. That function incorrectly returns success when copy_from_user() faults, btw. Oh. Better? Thanks, Kay From: Kay Sievers k...@vrfy.org Subject: kmsg: /dev/kmsg -

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Wed, 06 Jun 2012 00:55:00 +0200 Kay Sievers k...@vrfy.org wrote: On Tue, 2012-06-05 at 14:28 -0700, Andrew Morton wrote: devkmsg_writev() does weird and wonderful things with facilities/levels. That function incorrectly returns success when copy_from_user() faults, btw. Oh.

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote: What about writes starting with \001n? AFACIT, that will be stripped away and the printk level will be altered. This is new behavior. Nope. # echo \001Hello Andrew /dev/kmsg /dev/kmsg has 12,774,2462339252;\001Hello Andrew 12 is 8 +

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote: What about writes starting with \001n?  AFACIT, that will be stripped away and the printk level will be altered.  This is new behavior. Nope. # echo \001Hello Andrew

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 1:35 AM, Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:29 -0700, Andrew Morton wrote: What about writes starting with \001n? AFACIT, that will be stripped away and the printk level will be altered.

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote: Try echo -e? The stuff is copied verbatim otherwise. btw: I didn't change the devkmsg_writev function which does the decoding of any n prefix for printk_emit. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches j...@perches.com wrote: On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote: # echo \001Hello Andrew /dev/kmsg /dev/kmsg has 12,774,2462339252;\001Hello Andrew Try echo -e? The stuff is copied verbatim otherwise. # echo -e \001Hello Kay

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Tue, 05 Jun 2012 16:52:25 -0700 Joe Perches j...@perches.com wrote: On Wed, 2012-06-06 at 01:48 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 1:43 AM, Joe Perches j...@perches.com wrote: On Wed, 2012-06-06 at 01:39 +0200, Kay Sievers wrote: # echo \001Hello Andrew /dev/kmsg

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote: echo \0014Hello Joe /dev/kmsg # echo -e \x014Hello Me /dev/kmsg gives: 12,778,4057982669;Hello Me #echo -e \x011Hello Me_2 /dev/kmsg gives: 12,779,4140452093;Hello Me_2 I didn't change devkmsg_writev so the original parsing style for

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Wed, Jun 6, 2012 at 2:07 AM, Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote:  echo \0014Hello Joe /dev/kmsg # echo -e \x014Hello Me /dev/kmsg gives: 12,778,4057982669;Hello Me #echo -e \x011Hello Me_2 /dev/kmsg gives:

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote: The question is what happens if you inject your new binary two-byte prefix, like: echo -e \x01\x02Hello /dev/kmsg It's not a 2 byte binary. It's a leading ascii SOH and a standard ascii char '0' ... '7' or 'd'. #define KERN_EMERG

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches j...@perches.com wrote: On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote: The question is what happens if you inject your new binary two-byte prefix, like:   echo -e \x01\x02Hello /dev/kmsg It's not a 2 byte binary. It's a leading ascii SOH

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote: echo \0014Hello Joe /dev/kmsg # echo -e \x014Hello Me /dev/kmsg gives: 12,778,4057982669;Hello Me That's changed behavior. On Wed, 6 Jun 2012 02:28:39 +0200

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Wed, 2012-06-06 at 02:28 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 2:19 AM, Joe Perches j...@perches.com wrote: On Wed, 2012-06-06 at 02:13 +0200, Kay Sievers wrote: The question is what happens if you inject your new binary two-byte prefix, like: echo -e \x01\x02Hello

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote: echo \0014Hello Joe /dev/kmsg # echo -e \x014Hello Me /dev/kmsg gives: 12,778,4057982669;Hello

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Andrew Morton
On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 16:58 -0700, Andrew Morton wrote: echo \0014Hello Joe

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Kay Sievers
On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012 17:07:27 -0700 Joe Perches j...@perches.com wrote: On Tue,

Re: [PATCH 0/8] Rework KERN_LEVEL

2012-06-05 Thread Joe Perches
On Wed, 2012-06-06 at 03:10 +0200, Kay Sievers wrote: On Wed, Jun 6, 2012 at 2:46 AM, Andrew Morton a...@linux-foundation.org wrote: On Tue, 05 Jun 2012 17:40:05 -0700 Joe Perches j...@perches.com wrote: On Tue, 2012-06-05 at 17:37 -0700, Andrew Morton wrote: On Tue, 05 Jun 2012

Re: [PATCH 1/2] btrfs: Drop unused function btrfs_abort_devices()

2012-06-05 Thread Asias He
Hello, Jeff On 05/28/2012 09:41 PM, David Sterba wrote: On Fri, May 25, 2012 at 11:10:21AM +0800, Asias He wrote: 1) This function is not used anywhere. This was added in 49b25e0540904be0bf558b84475c69d72e4de66e adding a transaction abort infrastructure. I'm not sure if Jeff had some

[PATCH 9/8] printk: Only look for prefix levels in kernel messages

2012-06-05 Thread Joe Perches
vprintk_emit prefix parsing should only be done for internal kernel messages. This allows existing behavior to be kept in all cases. Signed-off-by: Joe Perches j...@perches.com --- kernel/printk.c | 32 +--- 1 files changed, 17 insertions(+), 15 deletions(-) diff