Re: Filesystem not mountable after reset, bad tree block
Hi! Michael Andreen schrieb: > The find-root program seems to think there is a root (and poentially some > older roots?), but not sure how to use that information. [...] > Anything else I can do to debug this or potentially recover a few bits > before reformatting? You could try the recovery programs from Josefs btrfs-progs tree[1]. You could also try using kernel 3.2 which allows mounting in recovery mode. This mode tries to find an older tree root. But I think your kernel did not keep tree root backups for this purpose as it is AFAIR a feature of later kernels. Better use a newer kernel - best use 3.2. There are bunch of fixes which improve the situation with lost file systems after unexpected reboots or power outages. HTH Kai [1] https://github.com/josefbacik/btrfs-progs -- 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: restriper interface
On Friday, 06 January, 2012 15:37:59 Ilya Dryomov wrote: > Hello, > > This is an update of userspace restriper interface. The main change is > that restriper commands have been moved under balance prefix. So now we > have: > > btrfs fi balance start > btrfs fi balance pause > btrfs fi balance cancel > btrfs fi balance resume > btrfs fi balance status > > This breaks btrfs-progs backwards compatibility: to get the old > balancing behaviour you have to call 'btrfs fi balance start' instead of > 'btrfs fi balance'. This is caused by stupidity of the core sub-command > matcher. Hi Ilya, what you called "stupidity of the core sub-command matcher" was a design decision. If you make "btrfs balance" a both command and a prefix you (my opinion) confuses a possible user and complex the interface: for example what means: # btrfs filesystem balance pause when 'pause' (and all the valid abbreviation like "pa" or "p" ) is a valid mount point ? My opinion, in order to not break the backward compatibility is to add another subcommand family, like 'restriper' or whatsoever, then deprecating the 'balance' sub command. Finally, please could you update the man page too ? BR G.Baroncelli Disclaimer, I was the author of the sub-command matcher. -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: restriper interface
On Sat, Jan 07, 2012 at 01:48:44PM +0100, Goffredo Baroncelli wrote: > On Friday, 06 January, 2012 15:37:59 Ilya Dryomov wrote: > > Hello, > > > > This is an update of userspace restriper interface. The main change is > > that restriper commands have been moved under balance prefix. So now we > > have: > > > > btrfs fi balance start > > btrfs fi balance pause > > btrfs fi balance cancel > > btrfs fi balance resume > > btrfs fi balance status > > > > This breaks btrfs-progs backwards compatibility: to get the old > > balancing behaviour you have to call 'btrfs fi balance start' instead of > > 'btrfs fi balance'. This is caused by stupidity of the core sub-command > > matcher. > > Hi Ilya, > > what you called "stupidity of the core sub-command matcher" was a design > decision. > > If you make "btrfs balance" a both command and a prefix you (my opinion) > confuses a possible user and complex the interface: > > for example what means: > > # btrfs filesystem balance pause > > when 'pause' (and all the valid abbreviation like "pa" or "p" ) is a valid > mount point ? pause needs an argument so technically we have a way out here, but at the expense of an awful interface (because then we have to be able to deal with sub-commands with no arguments, etc) You are right, I was too quick to call it stupid. I guess my problem is that I never bought this "the shortest abbreviation possible" thing. IMHO it would be much better if we had our long names and a handful of predefined abbreviations (like ip command for example). > > My opinion, in order to not break the backward compatibility is to add > another > subcommand family, like 'restriper' or whatsoever, then deprecating the > 'balance' sub command. It was that way initially, but half of what restriper does is selective balancing. The other half is profile changing, but that also boils down to a balance. So I decided not to introduce another obscure term. As for compatibility, I guess we will have to eat it and have everybody switch from "btrfs fi balance" to "btrfs fi balance start" if we want that shortest match behaviour. However if people feel strong about it I surely can put it under "restripe" and keep "btrfs fi balance" intact. Chris ? > > Finally, please could you update the man page too ? I will, this version was not intended for pulling anyway because of this problem. 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: [PATCH] Btrfs-progs: restriper interface
On Sat, 7 Jan 2012 16:25:29 +0200 Ilya Dryomov wrote: > IMHO it would be much better if we had our long names and a handful of > predefined abbreviations (like ip command for example). Does the ip command use just a handful of predefined abbrebiations? ip addr show ip add sho ip ad sh ip a s all work. which suggests to me they use exactly the same scheme as btrfs currently. -- With respect, Roman ~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." signature.asc Description: PGP signature
Re: [PATCH] Btrfs-progs: restriper interface
On Sat, Jan 07, 2012 at 08:32:51PM +0600, Roman Mamedov wrote: > On Sat, 7 Jan 2012 16:25:29 +0200 > Ilya Dryomov wrote: > > > IMHO it would be much better if we had our long names and a handful of > > predefined abbreviations (like ip command for example). > > Does the ip command use just a handful of predefined abbrebiations? > > ip addr show > ip add sho > ip ad sh > ip a s > > all work. > which suggests to me they use exactly the same scheme as btrfs currently. Look at ntbl for ntable, tunl for tunnel, tap for tuntap, lst for list, etc. On top af that they are using a "first match" policy, which leads to a very simple and clean code and is not at all what btrfs uses: ip route ip rout ip rou ip ro ip r all work and expand to "ip route" and if you want the "rule" sub-command, you have to use ip ru at the very least. btrfs instead tries to be clever, and if ip was doing the same thing btrfs does you would get "ambiguous command 'r'" error in response to "ip r". 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: Filesystem not mountable after reset, bad tree block
On Sat, Jan 07, 2012 at 01:05:08PM +0100, Kai Krakow wrote: > Hi! > > Michael Andreen schrieb: > > The find-root program seems to think there is a root (and poentially some > > older roots?), but not sure how to use that information. > [...] > > Anything else I can do to debug this or potentially recover a few bits > > before reformatting? > > You could try the recovery programs from Josefs btrfs-progs tree[1]. You'll find what little documentation we have on the restore program here: http://btrfs.ipv5.de/index.php?title=Restore With luck, you'll just need to run restore, but there's also a little bit on how to read and use the output of find-root. Hugo. > You > could also try using kernel 3.2 which allows mounting in recovery mode. This > mode tries to find an older tree root. But I think your kernel did not keep > tree root backups for this purpose as it is AFAIR a feature of later > kernels. > > Better use a newer kernel - best use 3.2. There are bunch of fixes which > improve the situation with lost file systems after unexpected reboots or > power outages. > > HTH > Kai > > [1] https://github.com/josefbacik/btrfs-progs > -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Computer Science is not about computers, any more than --- astronomy is about telescopes. signature.asc Description: Digital signature
Re: [PATCH] Btrfs-progs: restriper interface
On Saturday, 07 January, 2012 16:14:43 you wrote: > On Sat, Jan 07, 2012 at 08:32:51PM +0600, Roman Mamedov wrote: > > On Sat, 7 Jan 2012 16:25:29 +0200 > > > > Ilya Dryomov wrote: > > > IMHO it would be much better if we had our long names and a handful of > > > predefined abbreviations (like ip command for example). > > > > Does the ip command use just a handful of predefined abbrebiations? > > > > ip addr show > > ip add sho > > ip ad sh > > ip a s > > > > all work. > > which suggests to me they use exactly the same scheme as btrfs currently. > > Look at ntbl for ntable, tunl for tunnel, tap for tuntap, lst for list, > etc. On top af that they are using a "first match" policy, which leads > to a very simple and clean code and is not at all what btrfs uses: > > ip route > ip rout > ip rou > ip ro > ip r > > all work and expand to "ip route" > > and if you want the "rule" sub-command, you have to use > > ip ru > > at the very least. > > btrfs instead tries to be clever, and if ip was doing the same thing > btrfs does you would get "ambiguous command 'r'" error in response to > "ip r". You are right, but this is a bug. 1) btrfs s sn -> means btrfs subvolume snapshot 2) btrfs s se -> means btrfs subvolume set-default 3) btrfs s s -> is ambiguous command because it could means both 1) and 2) However if we try 1) we get an error. But this is not the intended behavior. I have to investigate why. BR G.Baroncelli > > Thanks, > > Ilya -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: restriper interface
On Saturday, 07 January, 2012 17:49:01 Goffredo Baroncelli wrote:
> On Saturday, 07 January, 2012 16:14:43 you wrote:
[..]
> > btrfs instead tries to be clever, and if ip was doing the same thing
> > btrfs does you would get "ambiguous command 'r'" error in response to
> > "ip r".
>
> You are right, but this is a bug.
>
> 1) btrfs s sn -> means btrfs subvolume snapshot
> 2) btrfs s se -> means btrfs subvolume set-default
> 3) btrfs s s -> is ambiguous command because it could means both 1) and 2)
>
> However if we try 1) we get an error. But this is not the intended
> behavior. I have to investigate why.
The change should be quite simple
diff --git a/btrfs.c b/btrfs.c
index 1def354..981afa4 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -268,8 +268,8 @@ static int check_ambiguity(struct Command *cmd, char
**argv)
if( cp->ncmds < i )
continue;
- for( skip = 0, j = 0 ; j < i ; j++ )
- if( strcmp(cmd->cmds[j], cp->cmds[j])){
+ for( skip = 0, j = 0 ; j <= i ; j++ )
+ if( !strcmp(cmd->cmds[j], cp->cmds[j])){
skip=1;
break;
}
But before issue a new patch I want to be sure about its correctness. I have
to make a more formal test.
>
> BR
> G.Baroncelli
>
> > Thanks,
> >
> > Ilya
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo)
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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
How to fill a new created btrfs file system?
Hi, using a 3.1.5 kernel (on Systemrescuecd) I cannot fill a newly created btrfs file system (mounted with -o compress) by extracting a (large) tar- file. I always get LOTS of "no space left on device"! Copying the same data again by extracting the tar-file once again, this seems to get fixed. What can I do about it? Has it been fixed with 3.2 ? (Unfortunately, I don't have a rescue cd with a 3.2 kernel, yet) Thanks for some hints, Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany -- 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: [3.2-rc7] slowdown, warning + oops creating lots of files
2012/1/5 Chris Mason : > On Fri, Jan 06, 2012 at 07:12:16AM +1100, Dave Chinner wrote: >> On Thu, Jan 05, 2012 at 02:45:00PM -0500, Chris Mason wrote: >> > On Thu, Jan 05, 2012 at 01:46:57PM -0500, Chris Mason wrote: >> > > On Thu, Jan 05, 2012 at 10:01:22AM +1100, Dave Chinner wrote: >> > > > On Thu, Jan 05, 2012 at 09:23:52AM +1100, Chris Samuel wrote: >> > > > > On 05/01/12 09:11, Dave Chinner wrote: >> > > > > >> > > > > > Looks to be reproducable. >> > > > > >> > > > > Does this happen with rc6 ? >> > > > >> > > > I haven't tried. All I'm doing is running some benchmarks to get >> > > > numbers for a talk I'm giving about improvements in XFS metadata >> > > > scalability, so I wanted to update my last set of numbers from >> > > > 2.6.39. >> > > > >> > > > As it was, these benchmarks also failed on btrfs with oopsen and >> > > > corruptions back in 2.6.39 time frame. e.g. same VM, same >> > > > test, different crashes, similar slowdowns as reported here: >> > > > http://comments.gmane.org/gmane.comp.file-systems.btrfs/11062 >> > > > >> > > > Given that there is now a history of this simple test uncovering >> > > > problems, perhaps this is a test that should be run more regularly >> > > > by btrfs developers? >> > > >> > > Unfortunately, this one works for me. I'll try it again and see if I >> > > can push harder. If not, I'll see if I can trade beer for some >> > > diagnostic runs. >> > >> > Aha, if I try it just on the ssd instead of on my full array it triggers >> > at 88M files. Great. >> >> Good to know. The error that is generating the BUG on my machine is >> -28 (ENOSPC). Given there's 17TB free on my filesystem > > Yeah, same thing here. I'm testing a fix now, it's pretty dumb. We're > not allocating more metadata chunks from the drive because of where the > allocation is happening, so it is just a check for "do we need a new > chunk" in the right place. > > I'll make sure it can fill my ssd and then send to you. Could you send the patch to the list (or to me), please? Telling from what you mentioned on IRC this sounds quite interesting and I would like to see if this solves my performance problems with ceph, too... Thanks, Christian -- 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
