On 06/11/2013 03:40 AM, Josef Bacik wrote:
On Mon, Jun 10, 2013 at 08:59:15AM -0600, Anand Jain wrote:
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
from the kernel respectively.
The information in these structure
On Tue, Jun 11, 2013 at 07:10:12AM -0600, anand jain wrote:
On 06/11/2013 03:40 AM, Josef Bacik wrote:
On Mon, Jun 10, 2013 at 08:59:15AM -0600, Anand Jain wrote:
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
On 06/11/2013 04:00 AM, Eric Sandeen wrote:
On 6/10/13 9:56 AM, Anand Jain wrote:
btrfs_scan_for_fsid uses only one argument run_ioctl out of 3
so remove the rest two of them
and run_ioctl is only ever '1' (and it's completely unobvious
at the call point what '1' means).
There was this
On 06/11/2013 04:30 AM, Zach Brown wrote:
On Mon, Jun 10, 2013 at 10:59:15PM +0800, Anand Jain wrote:
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
from the kernel respectively.
Why not just use sysfs to export the
On Mon, Jun 10, 2013 at 08:59:15AM -0600, Anand Jain wrote:
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
from the kernel respectively.
The information in these structure are useful to report the
device/fs
I'm also seeing this hang regularly with both 3.9 and 3.10-rc5. Is this
is a known problem? In this case there is no powercycling; just a regular
ceph-osd workload.
Thanks-
sage
[ 2885.479116] INFO: task kworker/u64:1:28713 blocked for more than 120 seconds.
[ 2885.486277] echo 0
With this array I have to mount -o degraded, even though all devices are
present.
Linux cartman 3.9.0 #1 SMP PREEMPT Fri May 3 22:02:21 EDT 2013 x86_64
GNU/Linux
btrfs-tools
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git *
master 7854c8b
When I try and mount without
On 11/06/2013, at 16:00, David Sterba dste...@suse.cz wrote:
On Mon, Jun 10, 2013 at 09:07:55PM +0100, Filipe David Borba Manana wrote:
--- a/disk-io.c
+++ b/disk-io.c
@@ -1267,12 +1267,12 @@ static int close_all_devices(struct btrfs_fs_info
*fs_info)
while (!list_empty(list)) {
Quoting Sage Weil (2013-06-11 11:43:30)
I'm also seeing this hang regularly with both 3.9 and 3.10-rc5. Is this
is a known problem? In this case there is no powercycling; just a regular
ceph-osd workload.
Everyone here is waiting for the root node, but it isn't immediately
clear who has the
1) Have a simple single fixed input structure for each ioctl. Maybe
with some extra padding and a flags argument if you think stuff is going
to be added over time. No generic header. No casting. The ioctl
number defines the input structure. If you need a different structure
later, use a
Hey,
I've a 2x4TB RAID1 setup with btrfs on kernel 3.8.0. Under high I/O load
(BackupPC dump or writing a large file over gigabit) I get messages in
syslog such as the one mentioned in the subject.
The full non-logcheck-ignored log is under [1].
A BackupPC dump between the same exact machines
Hey,
I've a 2x4TB RAID1 setup with btrfs on kernel 3.8.0. Under high I/O load
(BackupPC dump or writing a large file over gigabit) I get messages in
syslog such as the one mentioned in the subject.
The full non-logcheck-ignored log is under [1].
A BackupPC dump between the same exact machines
There's some 250+ lines here that are easily encapsulated into their own
function. I don't change how anything works here, just create and document
the new btrfs_clone() function from btrfs_ioctl_clone() code.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/ioctl.c | 232
This patch adds an ioctl, BTRFS_IOC_FILE_EXTENT_SAME which will try to
de-duplicate a list of extents across a range of files.
Internally, the ioctl re-uses code from the clone ioctl. This avoids
rewriting a large chunk of extent handling code.
Userspace passes in an array of file, offset pairs
The range locking in btrfs_ioctl_clone is trivially broken out into it's own
function. This reduces the complexity of btrfs_ioctl_clone() by a small bit
and makes that locking code available to future functions in
fs/btrfs/ioctl.c
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/ioctl.c |
Hi,
The following series of patches implements in btrfs an ioctl to do
offline deduplication of file extents.
To be clear, offline in this sense means that the file system is
mounted and running, but the dedupe is not done during file writes,
but after the fact when some userspace software
We want this for btrfs_extent_same. Basically readpage and friends do their
own extent locking but for the purposes of dedupe, we want to have both
files locked down across a set of readpage operations (so that we can
compare data). Introduce this variant and a flag which can be set for
Le 11/06/2013 22:31, Mark Fasheh a écrit :
Perhaps this isn't a limiation per-se but extent-same requires read/write
access to the files we want to dedupe. During my last series I had a
conversation with Gabriel de Perthuis about access checking where we tried
to maintain the ability for a
On Tue, Jun 11, 2013 at 10:56:59PM +0200, Gabriel de Perthuis wrote:
What I found however is that neither of these is a great idea ;)
- We want to require that the inode be open for writing so that an
unprivileged user can't do things like run dedupe on a performance
sensitive file
Le 11/06/2013 23:04, Mark Fasheh a écrit :
On Tue, Jun 11, 2013 at 10:56:59PM +0200, Gabriel de Perthuis wrote:
What I found however is that neither of these is a great idea ;)
- We want to require that the inode be open for writing so that an
unprivileged user can't do things like run
On Tue, Jun 11, 2013 at 11:31:41PM +0200, Gabriel de Perthuis wrote:
Le 11/06/2013 23:04, Mark Fasheh a écrit :
On Tue, Jun 11, 2013 at 10:56:59PM +0200, Gabriel de Perthuis wrote:
What I found however is that neither of these is a great idea ;)
- We want to require that the inode be open
These are some patches I've been sitting on for a while that I think
clean up the btrfs-progs tree a bit; there are still quite a few files
left in the top-level dir, but moving tests cmd files into cmd/
seems to clean things up a bit. Curious to see what people think.
This is just file-moves
Move test tools to tests/
Signed-off-by: Eric Sandeen sand...@redhat.com
---
Makefile | 23 +
tests/Makefile | 49
.../btrfs-corrupt-block.c |0
dir-test.c
Preparatory patch to move cmd test files into their
own subdirs.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
Makefile | 38 +++---
man/Makefile |1 -
2 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index
Move btrfs cmd files to cmd/ subdir
Signed-off-by: Eric Sandeen sand...@redhat.com
---
Makefile | 38 ++---
cmd/Makefile | 61
btrfs.c = cmd/btrfs.c |0
On Tue, Jun 11, 2013 at 06:15:16PM -0500, Eric Sandeen wrote:
These are some patches I've been sitting on for a while that I think
clean up the btrfs-progs tree a bit; there are still quite a few files
left in the top-level dir, but moving tests cmd files into cmd/
seems to clean things up a
Quoting Zach Brown (2013-06-11 19:24:46)
On Tue, Jun 11, 2013 at 06:15:16PM -0500, Eric Sandeen wrote:
These are some patches I've been sitting on for a while that I think
clean up the btrfs-progs tree a bit; there are still quite a few files
left in the top-level dir, but moving tests cmd
On 6/11/13 6:15 PM, Eric Sandeen wrote:
Move btrfs cmd files to cmd/ subdir
Signed-off-by: Eric Sandeen sand...@redhat.com
crud just realized this doesn't DTRT w/ btrfsck links, will have
to send a V2 for this one I guess.
-Eric
---
Makefile | 38
Move btrfs cmd files to cmd/ subdir
Signed-off-by: Eric Sandeen sand...@redhat.com
---
V2: move btrfsck symlink handling to cmd/Makefile too
Makefile | 38 ++---
cmd/Makefile | 61
Fix .gitignore for new file locations.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
(could update other patches rather than add 4th if it's better)
diff --git a/.gitignore b/.gitignore
index a7e1b19..abc7ca6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,17 +4,10 @@
version.h
version
30 matches
Mail list logo
