[PATCH] btrfs: move struct btrfs_ioctl_defrag_range_args from ctree.h to linux/btrfs.h

2014-10-07 Thread Marios Titas 
include/uapi/linux/btrfs.h is a more logical place to put the struct
btrfs_ioctl_defrag_range_args as it is being used by the
BTRFS_IOC_DEFRAG_RANGE IOCTL which is defined in that file.
Additionally, this is where the btrfs-progs defines that struct. Thus
this patches reduces the gap between the btrfs-progs headers and the
kernel headers.

Signed-off-by: Marios Titas red...@gmx.com
---
  fs/btrfs/ctree.h   | 31 ---
  include/uapi/linux/btrfs.h | 31 +++
  2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8e29b61..5e633cc 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1891,37 +1891,6 @@ struct btrfs_root {
atomic_t will_be_snapshoted;
  };
  
-struct btrfs_ioctl_defrag_range_args {
-   /* start of the defrag operation */
-   __u64 start;
-
-   /* number of bytes to defrag, use (u64)-1 to say all */
-   __u64 len;
-
-   /*
-* flags for the operation, which can include turning
-* on compression for this one defrag
-*/
-   __u64 flags;
-
-   /*
-* any extent bigger than this will be considered
-* already defragged.  Use 0 to take the kernel default
-* Use 1 to say every single extent must be rewritten
-*/
-   __u32 extent_thresh;
-
-   /*
-* which compression method to use if turning on compression
-* for this defrag operation.  If unspecified, zlib will
-* be used
-*/
-   __u32 compress_type;
-
-   /* spare for later */
-   __u32 unused[4];
-};
-
  
  /*
   * inode items have the data typically returned from stat and store other
diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
index 2f47824..d0e5757 100644
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -350,6 +350,37 @@ struct btrfs_ioctl_same_args {
struct btrfs_ioctl_same_extent_info info[0];
  };
  
+struct btrfs_ioctl_defrag_range_args {
+   /* start of the defrag operation */
+   __u64 start;
+
+   /* number of bytes to defrag, use (u64)-1 to say all */
+   __u64 len;
+
+   /*
+* flags for the operation, which can include turning
+* on compression for this one defrag
+*/
+   __u64 flags;
+
+   /*
+* any extent bigger than this will be considered
+* already defragged.  Use 0 to take the kernel default
+* Use 1 to say every single extent must be rewritten
+*/
+   __u32 extent_thresh;
+
+   /*
+* which compression method to use if turning on compression
+* for this defrag operation.  If unspecified, zlib will
+* be used
+*/
+   __u32 compress_type;
+
+   /* spare for later */
+   __u32 unused[4];
+};
+
  struct btrfs_ioctl_space_info {
__u64 flags;
__u64 total_bytes;
-- 
2.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Limits of BTRFS_IOC_LOGICAL_INO BTRFS_IOC_INO_PATHS

2014-02-24 Thread Marios Titas 
I was experimenting with the BTRFS_IOC_LOGICAL_INO 
BTRFS_IOC_INO_PATHS ioctls and noticed that there are some limits in
the kernel that limit the number or results they return. For example,
for BTRFS_IOC_LOGICAL_INO, the structure that will hold the results
can be up to 65536 bytes. Are there any plans to provide an
alternative way to access that information without the aforementioned
limits? This would be useful, for example, for userspace dedup
applications.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: check for reflink capability and for shared data

2013-08-26 Thread Marios Titas 
On Sat, Aug 24, 2013 at 12:09 PM, Thomas Koch tho...@koch.ro wrote:
 - check whether two files share the same data on disk, i.e. one has been
 created by cp --reflink of the other?

How about inspecting the output of filefrag -v $filename?
For example, you could filter out with grep all lines except the ones
that contain information about the extents.
Then you could hash the lines left and use that single hash to compare
the two files.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: update inode flags when renaming

2013-02-22 Thread Marios Titas 
Sorry, but the bug persists even with the above patch.

touch test
chattr +C test
lsattr test
mv test test2
lsattr test2

In the above scenario test2 will not have the C flag.

On Fri, Feb 22, 2013 at 3:11 AM, Liu Bo bo.li@oracle.com wrote:
 A user reported some weird behaviours,
 if we move a file with the noCow flag to a directory without the
 noCow flag, the file is now without the flag, but after remount,
 we'll find the file's noCow flag comes back.

 This is because we missed a proper inode update after inheriting
 parent directory's flags,

 Reported-by: Marios Titas redneb8...@gmail.com
 Signed-off-by: Liu Bo bo.li@oracle.com
 ---
  fs/btrfs/inode.c |7 +--
  1 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
 index d9984fa..d2e3352 100644
 --- a/fs/btrfs/inode.c
 +++ b/fs/btrfs/inode.c
 @@ -7478,8 +7478,6 @@ static int btrfs_rename(struct inode *old_dir, struct 
 dentry *old_dentry,
 old_dentry-d_inode,
 old_dentry-d_name.name,
 old_dentry-d_name.len);
 -   if (!ret)
 -   ret = btrfs_update_inode(trans, root, old_inode);
 }
 if (ret) {
 btrfs_abort_transaction(trans, root, ret);
 @@ -7514,6 +7512,11 @@ static int btrfs_rename(struct inode *old_dir, struct 
 dentry *old_dentry,
 }

 fixup_inode_flags(new_dir, old_inode);
 +   ret = btrfs_update_inode(trans, root, old_inode);
 +   if (ret) {
 +   btrfs_abort_transaction(trans, root, ret);
 +   goto out_fail;
 +   }

 ret = btrfs_add_link(trans, new_dir, old_inode,
  new_dentry-d_name.name,
 --
 1.7.7.6

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: update inode flags when renaming

2013-02-22 Thread Marios Titas 
Wouldn't though inheriting create all sorts of problems? For instance
check the example that I give in my other responese [1].

[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg22396.html

On Fri, Feb 22, 2013 at 4:34 AM, Miao Xie mi...@cn.fujitsu.com wrote:
 On  fri, 22 Feb 2013 16:40:35 +0800, Liu Bo wrote:
 On Fri, Feb 22, 2013 at 03:32:50AM -0500, Marios Titas wrote:
 Sorry, but the bug persists even with the above patch.

 touch test
 chattr +C test
 lsattr test
 mv test test2
 lsattr test2

 In the above scenario test2 will not have the C flag.

 What do you expect?  IMO it's right that test2 does not have the C flag.

 No, it's not right.
 For the users, they expect the C flag is not lost because they just do
 a rename operation. but fixup_inode_flags() re-sets the flags by the
 parent directory's flag.

 I think we should inherit the flags from the parent just when we create
 a new file/directory, in the other cases, just give a option to the users.
 How do you think about?

 Thanks
 Miao


 This patch ensure that we get the same result after we remount, no more
 the C flag coming back :)

 thanks,
 liubo


 On Fri, Feb 22, 2013 at 3:11 AM, Liu Bo bo.li@oracle.com wrote:
 A user reported some weird behaviours,
 if we move a file with the noCow flag to a directory without the
 noCow flag, the file is now without the flag, but after remount,
 we'll find the file's noCow flag comes back.

 This is because we missed a proper inode update after inheriting
 parent directory's flags,

 Reported-by: Marios Titas redneb8...@gmail.com
 Signed-off-by: Liu Bo bo.li@oracle.com
 ---
  fs/btrfs/inode.c |7 +--
  1 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
 index d9984fa..d2e3352 100644
 --- a/fs/btrfs/inode.c
 +++ b/fs/btrfs/inode.c
 @@ -7478,8 +7478,6 @@ static int btrfs_rename(struct inode *old_dir, 
 struct dentry *old_dentry,
 old_dentry-d_inode,
 old_dentry-d_name.name,
 old_dentry-d_name.len);
 -   if (!ret)
 -   ret = btrfs_update_inode(trans, root, old_inode);
 }
 if (ret) {
 btrfs_abort_transaction(trans, root, ret);
 @@ -7514,6 +7512,11 @@ static int btrfs_rename(struct inode *old_dir, 
 struct dentry *old_dentry,
 }

 fixup_inode_flags(new_dir, old_inode);
 +   ret = btrfs_update_inode(trans, root, old_inode);
 +   if (ret) {
 +   btrfs_abort_transaction(trans, root, ret);
 +   goto out_fail;
 +   }

 ret = btrfs_add_link(trans, new_dir, old_inode,
  new_dentry-d_name.name,
 --
 1.7.7.6

 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug: per file cow flag is lost when renaming

2013-01-28 Thread Marios Titas 
Try this:

touch test
chattr +C test
lsattr test
mv test test2
lsattr test2

The original file (test) will have the C flag but when renamed the
flag disappears. If the volume is unmounted and then mounted again the
flag reappears. However, if the file is modified in any way after the
renaming but before the umount/mount then even weirder things happen,
eg:

touch test
chattr +C test
head -c1048576 /dev/zero  test
lsattr test
# the C flag exists and the file does not COW when modified as expected
mv test test2
lsattr test2
# now the C flag disappeared
# if you modify the file it will COW and the flag will not
reappear after umount/mount

even worse, if you try to use BTRFS_IOC_CLONE to clone test2 to a
non-COW file with eg

cp --reflink test2 test3

it will fail with EINVAL as if the file test2 had the COW flag.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs send/receive symlink bug

2012-11-14 Thread Marios Titas 
On Wed, Nov 14, 2012 at 5:34 PM, David Arendt ad...@prnet.org wrote:
 Hi,

 I am using kernel 3.7.0-rc5 and latest btrfs-progs git.

 I am trying btrfs send/receive. When I have a filesystem containing a
 symlink pointing to a nonexistent destination or a destination created
 after the symlink was created, btrfs receive aborts with: ERROR: chown
 link1.txt failed. No such file or directory.

 Steps to reproduce (/dev/loop0 and /dev/loop1 are test images):

 mkfs.btrfs /dev/loop0
 mount /dev/loop0 /u00
 btrfs subvolume create /u00/test
 cd /u00/test
 ln -s test1.txt link1.txt
 btrfs subvolume snapshot -r /u00/test /u00/test.snapshot
 mkfs.btrfs /dev/loop1
 mount /dev/loop1 /u01
 btrfs send /u00/test.snapshot | btrfs receive /u01
 ERROR: chown link1.txt failed. No such file or directory


A patch [1] for btrfs-progs that solves this issue was posted a month
ago but has landed yet on the btrfs-progs git repository.

[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg19539.html
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cannot create subvolume with quota enabled

2012-09-11 Thread Marios Titas 
On Tue, Sep 11, 2012 at 2:19 AM, Arne Jansen sensi...@gmx.net wrote:

 instead of applying my patch, could you please just revert

 commit 5986802c2fcc754040bb7ed95f30bb16c4a843b7
 Author: Dan Carpenter dan.carpen...@oracle.com
 Date:   Mon Jul 30 02:16:10 2012 -0600

 Btrfs: fix some error codes in btrfs_qgroup_inherit()

 It introduces both faulty return codes.

Yes, reverting 5986802 and completely ignoring your earlier patch works.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Cannot create subvolume with quota enabled

2012-09-10 Thread Marios Titas 
On Fri, Sep 7, 2012 at 6:04 PM, Arne Jansen sensi...@gmx.net wrote:
 Hi Andreas,


 Thanks for giving quota a try. I sent a fix separately with
 the subject

 [PATCH] Btrfs: btrfs_qgroup_inherit wrongly returns an error

 Could you please see if it fixes the problem?

Even with this patch I still have a similar problem: When I try to
create a snapshot of an old subvolume that was created before I
enabled quotas, it fails. For new subvolumes it works just fine.
Here's an example ouput:

virtual ~ # btrfs sub snap /mnt/butter/old /mnt/butter/old-snap
Create a snapshot of '/mnt/butter/old' in '/mnt/butter/old-snap'
ERROR: cannot snapshot '/mnt/butter/old' - Invalid argument
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: No/bad auto-detection of fs type for small volumes (related to mixed metadata/data?)

2012-07-25 Thread Marios Titas 
On Wed, Jul 25, 2012 at 5:09 AM, cwillu cwi...@cwillu.com wrote:
 On Tue, Jul 24, 2012 at 6:39 PM, Marios Titas redneb8...@gmail.com wrote:
 When I create a btrfs volume of size strictly less than 256 MiB then if I do
 mount /dev/sdb1 /mnt/test
 the kernel tries unsuccessfully to do the mount with many other file systems
 before successfully trying with btrfs. For volumes of size larger than
 or equal to
 256 MiB it just mounts the volume without doing that. Why is this 
 discrepancy?

 If I understand correctly, the kernel does not implement any fs
 detection; this is performed by the mount utility, which indeed may
 try a bunch of different filesystems until it finds one that works.

 From man mount:
   If no -t option is given, or if  the  auto  type  is  specified,
   mount  will try to guess the desired type.  Mount uses the blkid
   or volume_id library for guessing the filesystem type;  if  that
   does not turn up anything that looks familiar, mount will try to
   read the file /etc/filesystems, or,  if  that  does  not  exist,
   /proc/filesystems.   All  of  the  filesystem types listed there
   will be tried, except for those that are labeled nodev  (e.g.,
   devpts,  proc and nfs).  If /etc/filesystems ends in a line with
   a single * only, mount will read /proc/filesystems afterwards.

Thanks, that was helpful. It was a blkid bug. It was fixed  [1] in
util-linux 2.21.

[1] https://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=04f7020
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

No/bad auto-detection of fs type for small volumes (related to mixed metadata/data?)

2012-07-24 Thread Marios Titas 
When I create a btrfs volume of size strictly less than 256 MiB then if I do
mount /dev/sdb1 /mnt/test
the kernel tries unsuccessfully to do the mount with many other file systems
before successfully trying with btrfs. For volumes of size larger than
or equal to
256 MiB it just mounts the volume without doing that. Why is this discrepancy?

Another possibly related symptom is that the volume does not appear in
/dev/disk/by-label and /dev/disk/by-uuid at all. This means that it is
impossible
to mount the volume by uuid or label.

To make sure that this isn't a udev bug, I booted my system with init=/bin/bash
in the kernel command line, and then I tried again to mount the
volume. This time
it would not mount it at all unless I explicitly specified the fs
type. On the other
hand, it could mount larger volumes without any issues.

All the experiments were done in an initially zeroed out disk. I am
using 3.4.6 kernel
with btrfs from 3.5 and the latest btrfs-progs from git.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature request: true RAID-1 mode

2012-06-20 Thread Marios Titas 
On Wed, Jun 20, 2012 at 12:27 PM, H. Peter Anvin h...@zytor.com wrote:
 Yet another boot loader support request.

 Right now btrfs' definition of RAID-1 with more than two devices is a
 bit unorthodox: it stores on any two drives.  True RAID-1 would
 instead store N copies on each of N devices, the same way an actual
 RAID-1 would operate with an arbitrary number of devices.

 This means that a bootloader can consider a single device in isolation:
 if the firmware gives access only to a single device, it can be booted.
  Since /boot is usually a very small amount of data, this is a very
 reasonable tradeoff.

+1

In fact, the current RAID-1 should not have been called RAID-1 at all,
it is confusing.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] Btrfs: restriper

2012-01-08 Thread Marios Titas 
I tried this for many different scenarios and it seems to work pretty
well. I only ran into one problematic case: If you remove a device
from a multidevice filesystem it crashes. Here's how to reproduce it:

truncate -s1g /tmp/test1
truncate -s1g /tmp/test2
losetup /dev/loop1 /tmp/test1
losetup /dev/loop2 /tmp/test2
mkdir /tmp/test
./mkfs.btrfs -L test -d single -m single /dev/loop1 /dev/loop2
mount -o noatime /dev/loop1 /tmp/test
./btrfs dev del /dev/loop1 /tmp/test
./btrfs fi bal start /tmp/test

There is no actual restriping involved but the above example does work
corretly under 3.1+for-linus whereas it fails with your patches.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE

2012-01-08 Thread Marios Titas 
On Fri, Jan 6, 2012 at 12:57, David Sterba d...@jikos.cz wrote:
 On Fri, Jan 06, 2012 at 02:04:12PM +0200, Konstantinos Skarlatos wrote:
 Me too wants cp --reflink across subvolumes. Please make this feature
 available to us, as its a poor man's dedupe and would give big space
 savings for many use cases.

 The simple case of 'cp --reflink' works fine [...]

It doesn't work here:

cp: failed to clone `/tmp/test': Invalid cross-device link

That's with 3.1 + for-linus.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html