On 08/30/12 13:55, Jie Liu wrote:
On 08/30/12 13:44, Anand Jain wrote:
Jeff,
I don't find the get label ioctl part unless I am missing something.
Any idea?
Sorry, I took for granted that this patch has already been merged last
year. :(
To honor your efforts, I'd like to re-send a revised
The original patch could be revised with this support easily.
How about using one structure and one ioctl number for both of them? i.e,
#define BTRFS_IOC_FSLABEL_CTL_IOW(BTRFS_IOCTL_MAGIC, 50, struct
btrfs_ioctl_fslabel_ctl_args)
#define BTRFS_FSLABEL_CTL_GET0
#define
On 08/30/12 14:28, Anand Jain wrote:
The original patch could be revised with this support easily.
How about using one structure and one ioctl number for both of them?
i.e,
#define BTRFS_IOC_FSLABEL_CTL_IOW(BTRFS_IOCTL_MAGIC, 50, struct
btrfs_ioctl_fslabel_ctl_args)
#define
I've been trying out different leafsize/nodesize settings by
benchmarking some typical operations.
These changes had more impact than I expected. Using a
leafsize/nodesize of either 8192 or 16384 provided a noticeable
improvement in my limited testing.
These results are similar to some that
On Thu, Aug 30, 2012 at 09:18:07AM -0600, Mitch Harder wrote:
I've been trying out different leafsize/nodesize settings by
benchmarking some typical operations.
These changes had more impact than I expected. Using a
leafsize/nodesize of either 8192 or 16384 provided a noticeable
On 08/28/2012 09:52 PM, M G Berberich wrote:
Hello,
We had set up a btrfs-fs over 6 hot-plugable SAS-disks for
testing and got it into a state where kernel and btrfs-tools do not
agree any more about the state of the filesystem.
We do not remember exaclty what we did, but roughly it was
Hi Anand,
please updates the man page, because it says that it is impossible to
change the label of a mounted filesystem
[...]
btrfs filesystem label dev [newlabel]
Show or update the label of a filesystem. dev is used to iden‐
tify the filesystem. If a newlabel optional
On Thu, Aug 30, 2012 at 08:24:53PM +0200, Goffredo Baroncelli wrote:
On 08/28/2012 09:52 PM, M G Berberich wrote:
(7) reinserted disk (and rebooted)
At some point before reboot the first 10 sectors of one disk
were zeroed to test if the disk gets removed from the btrfs.
IIRC the
Am Donnerstag, 30. August 2012 schrieb Josef Bacik:
On Thu, Aug 30, 2012 at 09:18:07AM -0600, Mitch Harder wrote:
I've been trying out different leafsize/nodesize settings by
benchmarking some typical operations.
These changes had more impact than I expected. Using a
leafsize/nodesize
On Thu, Aug 30, 2012 at 03:34:49PM -0600, Martin Steigerwald wrote:
Am Donnerstag, 30. August 2012 schrieb Josef Bacik:
On Thu, Aug 30, 2012 at 09:18:07AM -0600, Mitch Harder wrote:
I've been trying out different leafsize/nodesize settings by
benchmarking some typical operations.
These three patches (in combination with btrfs-next) fix things up for me!
Sage Weil (3):
Btrfs: pass lockdep rwsem metadata to async commit transaction
Btrfs: set journal_info in async trans commit worker
Btrfs: do not take cleanup_work_sem in btrfs_run_delayed_iputs()
fs/btrfs/inode.c
We expect current-journal_info to point to the trans handle we are
committing.
Signed-off-by: Sage Weil s...@inktank.com
---
fs/btrfs/transaction.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index efc41a5..f910a26 100644
---
The freeze rwsem is taken by sb_start_intwrite() and dropped during the
commit_ or end_transaction(). In the async case, that happens in a worker
thread. Tell lockdep the calling thread is releasing ownership of the
rwsem and the async thread is picking it up.
XFS plays the same trick in
Josef has suggested that this is not necessary. Removing it also avoids
this lockdep splat (after the new sb_internal locking stuff was added):
[ 604.090449] ==
[ 604.114819] [ INFO: possible circular locking dependency detected ]
[
On Thu, Aug 30, 2012 at 03:50:08PM -0600, Josef Bacik wrote:
On Thu, Aug 30, 2012 at 03:34:49PM -0600, Martin Steigerwald wrote:
I wonder what a good value for SSD might be. I tend to not use anymore
than 16k, but thats just some gut feeling right now. Nothing based on a
well-founded
On Thu, 30 Aug 2012 23:34:49 +0200
Martin Steigerwald mar...@lichtvoll.de wrote:
I wanted to ask about 32k either.
I used 32k on one 2,5 inch external esata disk. But I never measured
anything so far.
I wonder what a good value for SSD might be. I tend to not use anymore
than 16k, but
From: Liu Bo liub.li...@gmail.com
This is a collection of some posted patches.
It is also available in
git://github.com/liubogithub/btrfs-work.git
Liu Bo (5):
Btrfs: fix a bug of per-file nocow
Btrfs: update delayed ref's tracepoints to show sequence
Btrfs: fix a bug in parsing
Users report a bug, the reproducer is:
$ mkfs.btrfs /dev/loop0
$ mount /dev/loop0 /mnt/btrfs/
$ mkdir /mnt/btrfs/dir
$ chattr +C /mnt/btrfs/dir/
$ dd if=/dev/zero of=/mnt/btrfs/dir/foo bs=4K count=10;
$ lsattr /mnt/btrfs/dir/foo
---C- /mnt/btrfs/dir/foo
$ filefrag /mnt/btrfs/dir/foo
From: liubo liubo2...@cn.fujitsu.com
As ref cache has been removed from btrfs, there is no user on
its lock and its check.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/ctree.h |3 ---
fs/btrfs/disk-io.c |5 -
2 files
We've added a new field 'sequence' to delayed ref node, so update related
tracepoints.
Signed-off-by: Liu Bo bo.li@oracle.com
---
include/trace/events/btrfs.h | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/btrfs.h
From: Liu Bo liub.li...@gmail.com
In logical resolve, we parse extent_from_logical()'s 'ret' as a kind of flag.
It is possible to lose our errors because
(-E BTRFS_EXTENT_FLAG_TREE_BLOCK) is true.
I'm not sure if it is on purpose, it just looks too hacky if it is.
I'd rather use a real
We already have a helper, iterate_inodes_from_logical(), for logical resolve,
so just use it.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/ioctl.c | 19 +++
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index
This is the change of the kernel side.
Translation of logical to inode used to have an upper limit 4k on
inode container's size, but the limit is not large enough for a data
with a great many of refs, so when resolving logical address,
we can end up with
ioctl ret=0, bytes_left=0,
Add an option 's' to set bufsize in logical to inode transition, then we are
able
to read all the refs to the logical address.
Meanwhile, set a max value 64k for the bufsize.
Signed-off-by: Liu Bo bo.li@oracle.com
---
v2-v3: - use 64k as the upper limit
- document command's options
24 matches
Mail list logo
