Re: [patch 0/2] grub-0.97: btrfs support
Johannes Hirte wrote:
Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte:
Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin:
Hello everyone.
...
The following patches are for Fedora 10(**).
The distro-independent package will be put to kernel.org a bit later.
All comments, bugreports, etc. are welcome as usual.
Ok, I have another comment/bugreport *g*.
I'm testing this patch with gentoo, so the grub sources are not identicaly
the same. With this patches applied, grub is unable to detect JFS or XFS
filesystems. XFS is reported as unknown, JFS is reported as btrfs.
Reiserfs and ext2/3 are detected as expected.
Yes, this patch is for Fedora. For other distros
some issues are possible, so please be careful..
Thanks,
Edward.
A possible solution is to put FSYS_BTRFS on the end of struct fsys_entry
fsys_table. I've tested with FSYS_BTFS as the second last entry, the last is
still FFS.
diff -Nru grub-0.97-r9/stage2/disk_io.c grub-0.97-r10/stage2/disk_io.c
--- grub-0.97-r9/stage2/disk_io.c 2009-12-10 23:41:37.0 +0100
+++ grub-0.97-r10/stage2/disk_io.c 2009-12-11 00:50:51.555007247 +0100
@@ -79,6 +79,9 @@
# ifdef FSYS_ISO9660
{iso9660, iso9660_mount, iso9660_read, iso9660_dir, 0, 0},
# endif
+# ifdef FSYS_BTRFS
+ {btrfs, btrfs_mount, btrfs_read, btrfs_dir, 0, btrfs_embed},
+# endif
/* XX FFS should come last as it's superblock is commonly crossing tracks
on floppies from track 1 to 2, while others only use 1. */
# ifdef FSYS_FFS
With this order, XFS and JFS filesystems are identified correct. But I think,
this is just a workaround.
regards,
Johannes
--
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 2/2] grub-0.97: btrfs multidevice configuration support
Johannes Hirte wrote: Am Dienstag 03 November 2009 01:59:39 schrieb Edward Shishkin: Johannes Hirte wrote: Why is the btrfs code dealing with network devices at all? Why not? :) I don't see the possiblity to get a btrfs filesystem this way. So as far as I understand this, it's complete useless. The CD support doesn't look very usefull too to me. It's possible to put a btrfs filesystem on a CD or DVD. But that seems rather theoretical. Ok, let's keep this theoretical possibility, I don't see wrong things here.. Thanks, Edward. -- 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: a question about btrfs_writepage
2009/12/11 Hu Ruihuan specter...@gmail.com: Hi all, I am puzzled about a question, everytime when btrfs_writepage is called, whethe the noeds in every levels of the fs tree will be updated. This is the case as I read in the code, but if this case, whether it will give rise to the low efficiency? Thanks! refer to the update of nodes, I mean a cow operation -- 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
Idea (laptop support) for Project_ideas
Hi all, I've seen a lot of interesting ideas on your wiki page. http://btrfs.wiki.kernel.org/index.php/Project_ideas I'd like to see one more: combining some features (snapshot, Incremental backups, Hybrid Storage, NFS support ) could lead to a file system for Laptops with disconnected mode support. For example: laptop user with home on file server or shared project workspace on file server. snapshot could be used to make local copy (cache for NFS mount) in connected mode hybird storage could combine local cache with remote file server, reading from cache and propagateing changes to fileserver. in disconnected mode user works with data in cache. incremental backup could be used for synch after reconnect. this would introduce a whole set of new problems, network latency, conflict resolution, security, etc. but it's an idea on how to expand btrfs usage to the mobile world. Regards Christian -- 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] grub-0.97: btrfs support
Am Freitag 11 Dezember 2009 16:27:54 schrieb Edward Shishkin: Johannes Hirte wrote: Am Freitag 11 Dezember 2009 12:17:29 schrieb Edward Shishkin: Johannes Hirte wrote: Am Freitag 11 Dezember 2009 00:15:46 schrieb Johannes Hirte: Am Freitag 25 September 2009 00:06:23 schrieb Edward Shishkin: Hello everyone. ... The following patches are for Fedora 10(**). The distro-independent package will be put to kernel.org a bit later. All comments, bugreports, etc. are welcome as usual. Ok, I have another comment/bugreport *g*. I'm testing this patch with gentoo, so the grub sources are not identicaly the same. With this patches applied, grub is unable to detect JFS or XFS filesystems. XFS is reported as unknown, JFS is reported as btrfs. Reiserfs and ext2/3 are detected as expected. Yes, this patch is for Fedora. For other distros some issues are possible, so please be careful.. I've also tested now with the fedora sources. There is the same bug. The btrfs patch breaks the filesystem detection. All filesystems after btrfs in fsys_table aren't detected. Moving btrfs to the end of fsys_table is a workaround but will interfere with FFS. So this should better be fixed in the btrfs-part of grub, so that it: a) doesn't missdetect a JFS filesystem as btrfs b) doesn't break the detection for remaining filesystems in the array. Hello. Yes, I confirm that xfs, etc. file systems are not detected, but missdetection jfs as btrfs looks rather fantastic :) Please, try the attached patch. Report if any problems. The patch works, but the problem with misdetected JFS filesystem still persists. It happens if the device contained a btrfs filesystem before. I assume that the JFS super block starts later on the device as the btrfs one do and jfs_mkfs doesn't clean the space ahead of the JFS super block. So if a JFS filesystem is created on a device that contained a btrfs before, btrfs_mount still detects the beginning of the old btrfs super block and reads crap later on. To avoid this, btrfs detection could be placed after JFS. Are there any objections against this? regards, Johannes -- 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
Snapshot mysteries (and an oops)
Hi all- I'm a bit mystified by snapshots. I think that there are some bugs in btrfsctl at least (or maybe its documentation). There's definitely at least one bug in the kernel. Here's some commands I just tried (vanilla 2.6.32, btrfs-progs from git today. test is a brand-new empty btrfs filesystem, mounted with default options). Questions and comments are inline: [test]# btrfsctl -S subvol1 . operation complete Btrfs v0.19-4-gab8fb4c [test]# touch subvol1/file1 [test]# btrfsctl -s snap1 subvol1 operation complete Btrfs v0.19-4-gab8fb4c [test]# ls snap1 file1 OK, so it looks like I can make a snapshot of a subvolume, and everything works as expected. [test]# mkdir dir2 [test]# touch dir2/file2 [test]# btrfsctl -s snap2 dir2 operation complete Btrfs v0.19-4-gab8fb4c [test]# ls snap2 dir2 snap1 subvol1 [test]# ls snap2/snap1 [test]# WTF? It looks like btrfsctl just snapshotted the subvolume containing dir2 instead of snapshotting the directory. I would have expected it to either snapshot just the directory or, if that's impossible, to fail. [test]# rm -rf snap1 rm: cannot remove directory `snap1': Directory not empty [test]# ls snap1 [test]# OK, so rmdir can't remove snapshots. (Is there any good reason for that?) [test]# btrfsctl -D snap1 ioctl:: No such file or directory [test]# btrfsctl -D snap1 . operation complete Btrfs v0.19-4-gab8fb4c I can't make any sense of that. What's the second parameter to -D supposed to do? [test]# btrfsctl -D subvol1 . operation complete Btrfs v0.19-4-gab8fb4c Phew. That worked :) [test]# rm -rf * OK, now I'm back to where I started. [test]# btrfsctl -S subvol2 . operation complete Btrfs v0.19-4-gab8fb4c [test]# touch subvol2/file [test]# ln subvol2/file file Segmentation fault Crap. I guess I wasn't supposed to try that. dmesg attached: Process ln (pid: 3153, threadinfo 88019694, task 8801a4149780) Stack: 88017a741e00 88018af585d0 000e 0 880196941e28 88018af585d0 88017a741e00 88017a7905d0 0 88017e4b3680 88017a790688 880196941e78 81105988 Call Trace: [81105988] vfs_link+0xd5/0x14a Thanks, Andy [811057e9] ? lookup_hash+0x3b/0x3f [81107eb1] sys_linkat+0xc4/0x121 [8106af52] ? up_read+0xe/0x10 [8141d2a9] ? do_page_fault+0x269/0x299 [81095e6c] ? audit_syscall_entry+0x11e/0x14a [81107f2c] sys_link+0x1e/0x22 [81011cf2] system_call_fastpath+0x16/0x1b Code: ff 85 c0 41 89 c6 ba 01 00 00 00 75 39 49 8b 44 24 20 48 89 da 4c 89 fe 4c 89 e7 49 89 45 e0 e8 8f dc ff ff 85 c0 41 89 c6 74 04 0f 0b eb fe 48 8b 45 b8 31 d2 48 89 de 4c 89 e7 48 8b 48 28 e8 RIP [a0bc4305] btrfs_link+0xcf/0x144 [btrfs] RSP 880196941dd8 ---[ end trace 95f0a8585b4e506f ]--- -- 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] Subvolume listing feature for ioctl.
On Wed, Nov 18, 2009 at 02:42:14PM +0900, TARUISI Hiroaki wrote: New feature to list up subvolume/snapshots under specified tree of file is introduced to ioctl. Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com --- fs/btrfs/ioctl.c | 283 +++ fs/btrfs/ioctl.h | 29 + 2 files changed, 312 insertions(+) I've been using this patch to work with my subvolume mounting patches, and it seems to have a problem where it will panic the box. At first I thought it was something that I did, but on a freshly mkfs'ed fs I can reproduce the panic without doing any of the subvolume mounting weirdness. If I do btrfsctl -l a couple of times it will panic. This most recent time I did a btrfsctl -l on an empty fs, created a subvolume, did a list again, created another subvolume, and tried to list again and the box paniced. I don't have time to look into this now, but I will look into it next week if you haven't had a chance to get to it before then. Thanks, Josef -- 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
[PATCH] Btrfs: add ioctl to set the default mount subvol
This patch needs to go along with my previous patch. This lets us set the
default dir item's location to whatever root we want to use as our default
mounting subvol. With this we don't have to use mount -o subvol=tree id
anymore to mount a different subvol, we can just set the new one and it will
just magically work. I've done some moderate testing with this, mostly just
switching the default mount around, mounting subvols and the default mount at
the same time and such, everything seems to work. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ioctl.c | 64 ++
fs/btrfs/ioctl.h |2 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index c157eb7..9b747a9 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1551,6 +1551,68 @@ out:
return ret;
}
+static long btrfs_ioctl_default_subvol(struct file *file, void __user *argp)
+{
+ struct inode *inode = fdentry(file)-d_inode;
+ struct btrfs_root *root = BTRFS_I(inode)-root;
+ struct btrfs_root *new_root;
+ struct btrfs_dir_item *di;
+ struct btrfs_trans_handle *trans;
+ struct btrfs_path *path;
+ struct btrfs_key location;
+ struct btrfs_disk_key disk_key;
+ u64 objectid = 0;
+ u64 dir_id;
+
+ if (copy_from_user(objectid, argp, sizeof(objectid)))
+ return -EFAULT;
+
+ if (!objectid)
+ objectid = root-root_key.objectid;
+
+ location.objectid = objectid;
+ location.type = BTRFS_ROOT_ITEM_KEY;
+ location.offset = (u64)-1;
+
+ new_root = btrfs_read_fs_root_no_name(root-fs_info, location);
+ if (IS_ERR(new_root))
+ return PTR_ERR(new_root);
+
+ if (btrfs_root_refs(new_root-root_item) == 0)
+ return -ENOENT;
+
+ path = btrfs_alloc_path();
+ if (!path)
+ return -ENOMEM;
+ path-leave_spinning = 1;
+
+ trans = btrfs_start_transaction(root, 1);
+ if (!trans) {
+ btrfs_free_path(path);
+ return -ENOMEM;
+ }
+
+ dir_id = btrfs_super_root_dir(root-fs_info-super_copy);
+ di = btrfs_lookup_dir_item(trans, root-fs_info-tree_root, path,
+ dir_id, default, 7, 1);
+ if (!di) {
+ btrfs_free_path(path);
+ btrfs_end_transaction(trans, root);
+ printk(KERN_ERR Umm, you don't have the default dir item,
+ this isn't going to work\n);
+ return -ENOENT;
+ }
+
+ btrfs_cpu_key_to_disk(disk_key, new_root-root_key);
+ btrfs_set_dir_item_key(path-nodes[0], di, disk_key);
+ btrfs_mark_buffer_dirty(path-nodes[0]);
+ btrfs_free_path(path);
+
+ btrfs_end_transaction(trans, root);
+
+ return 0;
+}
+
/*
* there are many ways the trans_start and trans_end ioctls can lead
* to deadlocks. They should only be used by applications that
@@ -1597,6 +1659,8 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_snap_create(file, argp, 1);
case BTRFS_IOC_SNAP_DESTROY:
return btrfs_ioctl_snap_destroy(file, argp);
+ case BTRFS_IOC_DEFAULT_SUBVOL:
+ return btrfs_ioctl_default_subvol(file, argp);
case BTRFS_IOC_DEFRAG:
return btrfs_ioctl_defrag(file);
case BTRFS_IOC_RESIZE:
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 18c554b..9e5074c 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -96,4 +96,6 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_SNAP_LISTING _IOWR(BTRFS_IOCTL_MAGIC, 16, \
struct btrfs_ioctl_subvol_args)
+#define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 17, u64)
+
#endif
--
1.5.4.3
--
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
[PATCH] Btrfs-progs: add command to set default subvol
This introduces a new btrfsctl option, -m, to allow you to set the default'ly
mounted subvolume. You can do
btrfsctl -m /your/subvolume
and that will make that subvolume the subvolume that is mounted by default, or
you can do
btrfsctl -m treeid /any/subvolume
and this will make the subvolume with tree id treeid the default'ly mounted
subvolume. You can get the treeid by using the listing option. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
btrfsctl.c | 17 +
ioctl.h|2 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/btrfsctl.c b/btrfsctl.c
index 064c0d0..81d2a30 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -29,6 +29,7 @@
#include unistd.h
#include dirent.h
#include libgen.h
+#include stdlib.h
#include kerncompat.h
#include ctree.h
#include transaction.h
@@ -58,6 +59,8 @@ static void print_usage(void)
printf(\t-c: forces a single FS sync\n);
printf(\t-D: delete snapshot\n);
printf(\t-l file: listing snapshot/subvolume under a subvolume\n);
+ printf(\t-m [tree id] directory: set the default mounted subvolume
+ to the [tree id] or the directory\n);
printf(%s\n, BTRFS_BUILD_VERSION);
exit(1);
}
@@ -266,6 +269,7 @@ int main(int ac, char **av)
unsigned long command = 0;
int len;
char *fullpath;
+ u64 objectid = 0;
if (ac == 2 strcmp(av[1], -a) == 0) {
fprintf(stderr, Scanning for Btrfs filesystems\n);
@@ -380,6 +384,16 @@ int main(int ac, char **av)
exit(1);
}
command = BTRFS_IOC_SNAP_LISTING;
+ } else if (strcmp(av[i], -m) == 0) {
+ command = BTRFS_IOC_DEFAULT_SUBVOL;
+ if (i == ac - 3) {
+ objectid = (unsigned long long)
+ strtoll(av[i + 1], NULL, 0);
+ if (errno == ERANGE) {
+ fprintf(stderr, invalid tree id\n);
+ exit(1);
+ }
+ }
}
}
if (command == 0) {
@@ -410,6 +424,9 @@ int main(int ac, char **av)
ret = ioctl(snap_fd, command, args);
} else if (command == BTRFS_IOC_SNAP_LISTING) {
ret = btrfs_list_subvolumes(snap_fd, command);
+ } else if (command == BTRFS_IOC_DEFAULT_SUBVOL) {
+ printf(objectid is %llu\n, objectid);
+ ret = ioctl(fd, command, objectid);
} else
ret = ioctl(fd, command, args);
if (ret 0) {
diff --git a/ioctl.h b/ioctl.h
index 19020cb..70fc15d 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -91,4 +91,6 @@ struct btrfs_ioctl_subvol_leaf {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_SNAP_LISTING _IOWR(BTRFS_IOCTL_MAGIC, 16, \
struct btrfs_ioctl_subvol_args)
+#define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 17, u64)
+
#endif
--
1.5.4.3
--
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: (Little) Patch about null dereference with acl and posix.
Am Mittwoch 18 November 2009 22:28:27 schrieb briaeros007:
Hello,
For some days, i've got oops on my system and i've investigate it a bit.
The trouble was with posix_acl_equiv_mode , and for some reason
(corrupted metadata ?) btrfs sometimes call it with acl==NULL
This function doesn't like it.
So in my patch I've first put a little error protection around the
call, and then avoid to call btrfs_set_acl with acl=NULL.
I'm not sure if it's ok with best practice, but i've done the test
which produce the oops, and know it doesn't (but some csum failed.
Well if my btrfs is corrupted, it's comprehensible).
The patch is the following.
diff --git a/fs/btrfs/acl.c b/fs/btrfs/acl.c
index 3616042..f8ade24 100644
--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -111,7 +111,8 @@ static int btrfs_set_acl(struct inode *inode,
struct posix_acl *acl, int type)
switch (type) {
case ACL_TYPE_ACCESS:
mode = inode-i_mode;
- ret = posix_acl_equiv_mode(acl, mode);
+ if (acl mode)
+ ret = posix_acl_equiv_mode(acl, mode);
if (ret 0)
return ret;
ret = 0;
@@ -165,12 +166,13 @@ static int btrfs_xattr_set_acl(struct inode
*inode, int type,
} else if (IS_ERR(acl)) {
return PTR_ERR(acl);
}
+ else
+ {
+ ret = btrfs_set_acl(inode, acl, type);
+ posix_acl_release(acl);
+ }
}
- ret = btrfs_set_acl(inode, acl, type);
-
- posix_acl_release(acl);
-
return ret;
}
Shouldn't this go upstream and into stable review?
--
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] Subvolume listing feature for ioctl.
Thank you for your report. I'm going to reprocude this panic and fix it maybe next week. Regards, taruisi (2009/12/12 5:57), Josef Bacik wrote: On Wed, Nov 18, 2009 at 02:42:14PM +0900, TARUISI Hiroaki wrote: New feature to list up subvolume/snapshots under specified tree of file is introduced to ioctl. Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com --- fs/btrfs/ioctl.c | 283 +++ fs/btrfs/ioctl.h | 29 + 2 files changed, 312 insertions(+) I've been using this patch to work with my subvolume mounting patches, and it seems to have a problem where it will panic the box. At first I thought it was something that I did, but on a freshly mkfs'ed fs I can reproduce the panic without doing any of the subvolume mounting weirdness. If I do btrfsctl -l a couple of times it will panic. This most recent time I did a btrfsctl -l on an empty fs, created a subvolume, did a list again, created another subvolume, and tried to list again and the box paniced. I don't have time to look into this now, but I will look into it next week if you haven't had a chance to get to it before then. Thanks, Josef -- 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 -- taruisi -- 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
