Forgot citations, sorry!
On Tuesday 13 March 2012 11:13:28 Chris Samuel wrote:
> Note though that some people are reporting regressions with
> premature ENOSPC in 3.3-rc7, to quote:
>
> # - bisected down to 5500cdb (Btrfs: increase the global block
> # reserve estimates). After reverting this on
On Tuesday 13 March 2012 10:40:39 David Sterba wrote:
> (I just know that the flag is there and is related to the question,
> haven't tested it myself and do not know what was the original
> intention.)
Not sure it helps, but the commits for these were:
commit fdebe2bd70047e057827cba85ba31b2545e
On Tuesday 13 March 2012 11:04:35 Chris Mason wrote:
> This one was fixed in the 3.3 series. You can pull from my
> for-linus repo for a commit against 3.2.
Note though that some people are reporting regressions with premature
ENOSPC in 3.3-rc7, to quote:
# - bisected down to 5500cdb (Btrfs: i
Chester posted on Mon, 12 Mar 2012 14:52:47 -0500 as excerpted:
> On Mon, Mar 12, 2012 at 2:36 PM, Fong Vang wrote:
>> Does anyone know if there's a plan to provide an option to make a BTRFS
>> filesystem a WORM (write-one-read-many)? So essentially, once a file
>> has been written it cannot be
On Mon, Mar 12, 2012 at 09:32:54PM +0200, Avi Kivity wrote:
> Because I'm such a btrfs fanboi I'm running btrfs on my /, all past
> experience notwithstanding. In an attempt to recover some performance,
> I enabled autodefrag, and got this in return:
Hi Avi,
This one was fixed in the 3.3 series.
On Mon, Mar 12, 2012 at 12:36:13PM -0700, Fong Vang wrote:
> Does anyone know if there's a plan to provide an option to make a
> BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a
> file has been written it cannot be altered nor deleted. To delete
> would require a newfs. I kn
There's support for Read-only snapshots, so you might be able to use
that with some clever scripting =\
On Mon, Mar 12, 2012 at 2:36 PM, Fong Vang wrote:
> Does anyone know if there's a plan to provide an option to make a
> BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a
>
Does anyone know if there's a plan to provide an option to make a
BTRFS filesystem a WORM (write-one-read-many)? So essentially, once a
file has been written it cannot be altered nor deleted. To delete
would require a newfs. I know that there's extended attributes but
root can alter that on indi
Because I'm such a btrfs fanboi I'm running btrfs on my /, all past
experience notwithstanding. In an attempt to recover some performance,
I enabled autodefrag, and got this in return:
[567304.937620] [ cut here ]
[567304.938525] kernel BUG at fs/btrfs/inode.c:1588!
[56730
Commit bab2c565 accidentally broke 'subvol get-default' command by
removing almost all of the underlying code. Bring it back with some
fixes and improvements.
Signed-off-by: Ilya Dryomov
---
btrfs-list.c | 81 +-
ctree.h |2 +
2
Don't pass a pointer to root_id to resolve_root(). It's always the same as
ri->root_id, passing a pointer hints that root_id can somehow change which is
not true.
Signed-off-by: Ilya Dryomov
---
btrfs-list.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff
There's no need to zero out things twice.
Signed-off-by: Ilya Dryomov
---
btrfs-list.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index 5f4a9be..44a73de 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -569,10 +569,6 @@ static int __lis
'btrfs subvol get-default' has been broken for a while, fix it. Patches
1 and 2 are straightforward cleanups in that area, patch 3 fixes the
problem.
Thanks,
Ilya
Ilya Dryomov (3):
Btrfs-progs: nuke redundant zeroing in __list_subvol_search()
Btrfs-progs: refactor resolve_r
Am Mon, 12 Mar 2012 15:21:49 +0100
schrieb Jacek Luczak :
> > 2) A *regression* in 3.3.0-rc6-00197-g9f8050c
> > - completely unusable as reports ENOSPC
> > - to reproduce, mount volume and issue:
> > # CNT=1 ; while [ $CNT -lt 1 ] ; do rm -f /btrfs/dd ; ! touch
> > /btrfs/dd && echo "$CNT" &&
2012/3/10 Jacek Luczak :
> 2012/3/9 David Sterba :
>> On Fri, Mar 09, 2012 at 12:08:12PM +0100, Jacek Luczak wrote:
>>> For this one I've created also a report [1].
>>> >
>>> > so there is probably other problem in reservations and it just blew up
>>> > during
>>> > the unlink call.
>>>
>>> Could
Hello,
On Fri 09-03-12 14:40:22, Andor Daam wrote:
> Is it ever possible for a superblock for a mounted filesystem to be
> free'd without a previous call to unmount the filesystem?
No, I don't think so (well, except for cases where we do not manage to
fully setup the superblock). But be aware
clear_extent_bit()
{
next_node = rb_next(&state->rb_node);
...
clear_state_bit(state); <-- this may free next_node
if (next_node) {
state = rb_entry(next_node);
...
}
}
clear_state_bit() calls merge_state() which may free the next node
of the passing extent_sta
clear_extent_bit()
{
next_node = rb_next(&state->rb_node);
...
clear_state_bit(state); <-- this may free next_node
if (next_node) {
state = rb_entry(next_node);
...
}
}
clear_state_bit() calls merge_state() which may free the next node
of the passing extent_sta
Currently it returns a set of bits that were cleared, but this return
value is not used at all.
Moreover it doesn't seem to be useful, because we may clear the bits
of a few extent_states, but only the cleared bits of last one is
returned.
Signed-off-by: Li Zefan
---
fs/btrfs/extent_io.c | 19
19 matches
Mail list logo
