Re: [PATCH v0 07/18] btrfs: generic data structure to build unique lists

On 06.10.2011 22:33, Andi Kleen wrote: > Arne Jansen writes: > >> ulist is a generic data structures to hold a collection of unique u64 >> values. The only operations it supports is adding to the list and >> enumerating it. >> It is possible to store an auxiliary value along with the key. >> The

Re: [PATCH v0 03/18] btrfs: add nested locking mode for paths

On 06.10.2011 22:54, Andrey Kuzmin wrote: > > > On Friday, October 7, 2011, Andi Kleen > wrote: >> On Fri, Oct 07, 2011 at 12:44:30AM +0400, Andrey Kuzmin wrote: >>> Perhaps you could just elaborate on "needs this feature"? In general, write >>> lock gives one exclusi

Re: Honest timeline for btrfsck

> For fsck, even the stuff I have here does have a way to go before it is > at the level of an e2fsck or xfs_repair.  But I do want to make sure > that I'm surprised by any bugs before I send it out, and that's just not > the case today.  The release has been delayed because I've alternated > betwe

Re: Honest timeline for btrfsck

On 10/07/2011 09:40 AM, Jeff Putney wrote: >> For fsck, even the stuff I have here does have a way to go before it is >> at the level of an e2fsck or xfs_repair. But I do want to make sure >> that I'm surprised by any bugs before I send it out, and that's just not >> the case today. The release h

Re: Honest timeline for btrfsck

On 10/06/2011 04:56 PM, Francesco Riosa wrote: > 2011/10/6 Andi Kleen : >> Jeff Putney writes: >>> >>> http://en.wikipedia.org/wiki/Release_early,_release_often >> >> Well the other principle in free software you're forgetting >> is: >> >> "It will be released when it's ready" >> >> If you don't l

[PATCH] Btrfs: inline checksums into the space cache

Yeah yeah I know this is how we used to do it and then I changed it, but damnit I'm changing it back. The fact is that writing out checksums will modify metadata, which could cause us to dirty a block group we've already written out, so we have to truncate it and all of it's checksums and re-write

Re: [PATCH v0 07/18] btrfs: generic data structure to build unique lists

> As to the differences to idr: > - as David pointed out, idr works on int, while I always need u64 to >represent btrfs logical addresses. > - as I understand idr (though I never used it), it is designed to manage >small consecutive integers, while ulists hold completely unrelated >nu

Re: A Plumber’s Wish List for Linux

On Fri, Oct 07, 2011 at 02:46:23PM +0200, Kay Sievers wrote: > On Fri, Oct 7, 2011 at 12:38, Alan Cox wrote: > > On Fri, 7 Oct 2011 12:28:46 +0200 Kay Sievers wrote: > > > >> What do you mean would be ugly? > > > > I have an ext4fs. It supports every possible file name allowed by POSIX > > and Su

Re: Honest timeline for btrfsck

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Oct 07, 2011 at 10:50:04AM -0400, Josef Bacik wrote: > If you still need that data, clone this repo > > git://github.com/josefbacik/btrfs-progs.git > > run make, and then run > > ./restore /dev/whatever /some/dir > > and it will try and s

Re: Honest timeline for btrfsck

On 11-10-06 07:50 PM, Chris Mason wrote: That's how software goes sometimes, and I'll take the criticism because it hasn't gone as well as it should have. But, I can't stress enough how much I appreciate everyone's contributions and interest in btrfs. With all due respect Chris, your actions a

[PATCH] Btrfs: wait for ordered extents if we didn't reclaim enough

I noticed recently that my overcommit patch was causing one of my enospc tests to fail 25% of the time with early ENOSPC. This is because my overcommit patch was letting us go way over board, but it wasn't waiting long enough to let the delalloc shrinker do it's job. The problem is we just start

Re: Honest timeline for btrfsck

The rescue tool may have a lot of the logic I personally am most interested in reading. Thank you for that! > The problem is people won't just read it, they will use it. I've read every last line of the current btrfsck, even though it doesn't do anything. I am interested in the source specifica

Re: Honest timeline for btrfsck

On 10/07/2011 11:58 AM, Jeff Putney wrote: > The rescue tool may have a lot of the logic I personally am most > interested in reading. Thank you for that! > >> The problem is people won't just read it, they will use it. > > I've read every last line of the current btrfsck, even though it > doesn

read error: how to fix?

Hallo, I'm just copying about 1.5 TByte from a 3-disks-btrfs directory (data: raid0) to another disk. And there seem to be 2 damaged files, they stop the copying process. Oct 7 18:16:55 Arktur kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Oct 7 18:16:55 Arktur kernel:

Re: Honest timeline for btrfsck

You jest, but in fact that is the result you've achieved, through conspiring or not. Do you honestly believe that had the source been public from the start, that after a year there would still be no quality fsck tool? Contributions are, de facto, blocked. Had there not been repeated promise of an

Re: Honest timeline for btrfsck

On Fri, 07 Oct 2011 08:39:36 -0700 Mike wrote: > I also don't think you are giving people enough credit. e2fsck will > cause corruption pretty much everytime its run on a mounted file > system, but a nice big nasty warning message seems to handle that > quite well and anyone who ignores it, well

Re: Honest timeline for btrfsck

On Fri, Oct 7, 2011 at 11:07 AM, Jeff Putney wrote: > You jest, but in fact that is the result you've achieved, through > conspiring or not. > > Do you honestly believe that had the source been public from the > start, that after a year there would still be no quality fsck tool? > Contributions ar

Re: [RFC][PATCH 1/2] vfs: allow /proc/pid/maps to return a custom device

Ressurecting an old thread, sorry. Here's the conversation thus far: http://www.spinics.net/lists/linux-btrfs/msg10099.html This is still hitting folks wishing to use btrfs on suse based systems. Using getattr() (unconditionally I might add) is possible, but will affect performance to a far great

Re: Honest timeline for btrfsck

On 10/07/11 04:25, Chester wrote: The problem with this is that people naturally look for a fsck tool when something bad goes wrong. Something as important as a fsck utility shouldn't be released (unofficially or officially) half baked. It can irreparably destroy a filesystem which could've other

Re: Honest timeline for btrfsck

> What I would like to know instead, is WHY we need an btrfsck when ZFS does > not. Zfs also has this kind of problems especially on power failures, but > you can always mount by rolling back to a previous uberblock, showing an > earlier view of the filesystem, which would be consistent. > > It was

Re: Honest timeline for btrfsck

On Viernes, 7 de Octubre de 2011 21:10:33 Asdo escribió: > failures, but you can always mount by rolling back to a previous > uberblock, showing an earlier view of the filesystem, which would be > consistent. This is already available in Btrfs, command btrfsck -s. -- To unsubscribe from this lis

Re: Honest timeline for btrfsck

Hallo, Asdo, Du meintest am 07.10.11: > What I would like to know instead, is WHY we need an btrfsck when ZFS > does not. I need at least some tool which can "hide" defect sectors - I just have such a problem. Viele Gruesse! Helmut -- To unsubscribe from this list: send the line "unsubscribe

Re: Honest timeline for btrfsck

> Heh, what sort of "quality" are you thinking would develop?  A > recovery tool by its nature is picking up the pieces where those > pieces are inconsistent.  The nature of those inconsistencies will > change with every patch that's more than a cleanup. > Seriously? You want to delay the solving

stat returns wrong block count

Hi, recently I encountered weird (much too small) numbers returned by "du". It turns out that on some files btrfs returns a wrong number of used blocks. Two files, identical, non-zero, non-spare: # ls -l total 19296 <-- block count is wrong, sizes are correct -rw-r--r-- 1 marc root 19759104 Oct