What btrfs does for the btree inode is insane, and I'm pretty sure I
already complained about it. It really needs to stop registering that
inode with the writeback code and just driver it manually. Same as
other filesystems do for their "micro-managed" metadata.
--
To unsubscribe from this list:
On Fri, Oct 14, 2011 at 07:17:44AM +0200, krz...@gmail.com wrote:
> Just a idea: I don't know if btrfs works like that or not but idea
> would be that b-tree filesystem should be able to "loose" or "discard"
> branches be removing a node. Cut a tree node and branches will fall
> off - and get over
On Fri, Oct 14, 2011 at 09:04:28AM +0900, Tsutomu Itoh wrote:
> (2011/10/14 2:11), Josef Bacik wrote:
> > Recently I changed the xattr stuff to unconditionally set the xattr first in
> > case the xattr didn't exist yet. This has introduced a regression when
> > setting
> > an xattr that already e
Hallo, linux-btrfs,
I've just compiled kernel 3.9.04 and run
btrfs filesystem show
On my system (Slackware 13.37, self made, without "udev") it still shows
a lot of non existent devices (I have shortened the list ...):
# btrfs fi show
failed to read /dev/hdb4
failed to read /dev/scd9
On Fri, Oct 14, 2011 at 03:51:00PM +0200, Helmut Hullen wrote:
> Hallo, linux-btrfs,
>
> I've just compiled kernel 3.9.04 and run
Do you mean 3.0.4? We've not reached 3.2 yet, let alone 3.9 :) (Not
that it matters in this case).
> btrfs filesystem show
>
> On my system (Slackware 13.
Hallo, Hugo,
Du meintest am 14.10.11:
>> I've just compiled kernel 3.9.04 and run
>Do you mean 3.0.4? We've not reached 3.2 yet, let alone 3.9 :)
> (Not that it matters in this case).
Sorry - bending the fingers is a hard work ... (and looking for typos
too ...)
>This is not a kernel
Hallo, Hugo,
Du meintest am 14.10.11:
>This is not a kernel issue, it's a purely userspace issue. Try the
> latest integration branch from git.darksatanic.net, which should have
> a fix for it.
I've just tried
git clone git://git.darksatanic.net/repo/btrfs-progs-unstable.git
and got the
On Fri, Oct 14, 2011 at 04:59:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
> Du meintest am 14.10.11:
>
> >This is not a kernel issue, it's a purely userspace issue. Try the
> > latest integration branch from git.darksatanic.net, which should have
> > a fix for it.
>
> I've just tried
>
>
On Fri, Oct 14, 2011 at 05:14:32PM +0200, Tomasz Torcz wrote:
> On Fri, Oct 14, 2011 at 04:08:24PM +0100, Hugo Mills wrote:
> > On Fri, Oct 14, 2011 at 04:59:00PM +0200, Helmut Hullen wrote:
> > > Du meintest am 14.10.11:
> > > I've just tried
> > >
> > >git clone git://git.darksatanic.net/rep
the right
> ones, and I'm not aware of having any blocking in place from my
> service provider. Do you have a "transparent" proxy in the way?
Changing from "git://" to "http://"; solved the problem!
Compiling worked, see
<http://arktur.shuttle.de/CD/Testpak
On Thu, Oct 13, 2011 at 11:28:39AM +1100, Dave Chinner wrote:
> Yup. xfs_admin already provides an interface for offline
> modification of the UUID for XFS filesytems. I.e. clone the
> filesytem using xfs_copy, then run xfs_admin -U generate to
> generate a new uuid in the cloned copy before you m
Good afternoon btrfs,
I have been having issues with snapshots not reading the whole file tree
below them. I have installed new btrfs-progs from
git://git.darksatanic.net/repo/btrfs-progs-unstable.git
made and installed them. My tree is: /Btrfs |
On Fri, Oct 14, 2011 at 09:45:05AM +0100, Hugo Mills wrote:
> Updating and checking the reference count is the thing
> that takes time, and can't really be short-circuited.
I'm curious if you know how ZFS does this. My boss has used a set of
ZFS systems for backup, and indicates that deleting a
On Thu, 2011-10-13 at 23:03 +0200, krz...@gmail.com wrote:
>
> > If you delete a large number of files, then there is no avoiding the
> > fact that a lot of metadata needs to be updated. In this respect
> btrfs
> > is unlikely to be significantly faster than any other filing system.
>
> Are you s
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
Recently I changed the xattr stuff to unconditionally set the xattr first in
case the xattr didn't exist yet. This has introduced a regression when setting
an xattr that already exists with a large value. If we find the key we are
looking for split_leaf will assume that we're extending that item.
Before the only reason to commit the transaction to recover space in
reserve_metadata_bytes() was if there were enough pinned_bytes to satisfy our
reservation. But now we have the delayed inode stuff which will hold it's
reservations until we commit the transaction. So say we max out our reservat
The only way we actually reclaim delalloc space is waiting for the IO to
completely finish. Usually we kick off a bunch of IO and wait for a little bit
and hope we can make our reservation, and usually this works out pretty well.
With overcommit however we can get seriously underwater if we're fil
Currently we only allow a maximum of 2 megabytes of pages to be flushed at a
time. This was ok before, but now we have overcommit which will screw us in a
heartbeat if we are quickly filling the disk. So instead pick either 2
megabytes or the number of pages we need to reclaim to be safe again, w
On 10/14/2011 12:13 PM, Jim wrote:
Good afternoon btrfs,
I have been having issues with snapshots not reading the whole file
tree below them. I have installed new btrfs-progs from
git://git.darksatanic.net/repo/btrfs-progs-unstable.git
made and installed them. My tree is: /Btrfs |
Thank you for that info Anthony, I just wanted to know the expected
behavior. In that same vein, when I use btrfs sub list it lists all
subvols regardless of whether or not it is given a path argument. Is
this current behavior as well. Thanks again.
Jim
On 10/14/2011 02:17 PM, C Anthony Ris
We started setting trans->block_rsv = NULL to allow the delayed refs flushing
stuff to use the right block_rsv and then just made
btrfs_trans_release_metadata() unconditionally use the trans block rsv. The
problem with this is we need to reserve some space in the transaction and then
migrate it to
In __unlink_start_trans() if we don't have enough room for a reservation we will
check to see if the unlink will free up space. If it does that's great, but we
will still could add an orphan item, so we need to reserve enough space to add
the orphan item. Do this and migrate the space the global
Excerpts from Christoph Hellwig's message of 2011-10-14 03:18:02 -0400:
> What btrfs does for the btree inode is insane, and I'm pretty sure I
> already complained about it. It really needs to stop registering that
> inode with the writeback code and just driver it manually. Same as
> other files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/10/2011 11:58 AM, Helmut Hullen wrote:
> Hallo, Jeff,
>
> Du meintest am 10.10.11:
>
> Oct 7 18:16:55 Arktur kernel: ata5.00: exception Emask
> 0x0 SAct 0x0 SErr 0x0 action 0x0
>
> [...]
>
>>> I've just worked again with the 2 unread
On Friday, 14 October, 2011 17:43:00 you wrote:
[...]
>
> But "btrfs filesystem show" still shows lots of nonexistent devices -
> sorry.
You have to checkout the latest branch; so after
$ git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
you have to perform
$ c
Hallo, Goffredo,
Du meintest am 14.10.11:
> You have to checkout the latest branch; so after
> $ git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
> you have to perform
> $ cd btrfs-progs-unstable
> $ git checkout integration-20111012
> Hoping that that help
27 matches
Mail list logo
