Re: Can't mount removable device if device name changes.
Hi, What is your kernel version? Btrfs hols device names which construct filesystems and updating device name(device renaming) is merged just in last month. Regards, taruisi (2010/04/11 10:49), cwillu wrote: I've got a btrfs on an sd card, which I'm using as the root fs on a beagle. That's not the problem :) The machine I generate my images on has an internal sd reader, and I also have a usb card reader. After creating the fs on the internal reader, I ended up plugging it in on the external reader. internal: sdd external: sdh mount /dev/sdh2 /mnt -t btrfs mount: /dev/sdh2: can't read superblock [15035.538462] device fsid 48fadf7ed76537-bb9c7266ecb8b2 devid transid 8986 /dev/sdh2 [15035.538462] open /dev/sdd2 failed If I plug it back into the internal reader, it mounts fine on /dev/sdd2. An strace of btrfsctl -a shows it reading /dev/sdh2, and there's no mention of /dev/sdd: open(/dev/sdh2, O_RDONLY) = 4 pread(4, \2067kF\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 2859, 65536) = 2859 The fs mounts fine on the external reader on a different machine. -- 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
Re: Btrfs - Unable to mount, can't read superblock?
Hi, This disk was used as /dev/sdd previously, and now it's named /dev/sdc, isn't it? If so, you can use this usb disk after reboot, or adjusting that the disk is recognized as /dev/sdd. Btrfs does not support device file renaming yet. Regards, taruisi (2010/02/13 21:45), Victor Hooi wrote: heya, This is on kernel 2.6.32.8-1, on Arch Linux 64-bit. I have an external harddisk, with a btrfs filessystem on it. Just now, after a reboot, I seem to be unable to mount it. KDE gives a message about being unable to find the superblock, trying to mount it from the command-line gives something similar: mount: /dev/sdc1: can't read superblock I do know the last time I used the disk, it may not have been unmounted cleanly. Could that have caused this current issue? Any possible remedy? I'm really hoping it is, because that's a 1.5 Tb external disk...lol. Also, dmesg contains: usb 2-2: new high speed USB device using ehci_hcd and address 8 usb 2-2: configuration #1 chosen from 1 choice scsi10 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 8 usb-storage: waiting for device to settle before scanning scsi 10:0:0:0: Direct-Access WDC WD15 EADS-00P8B0 PQ: 0 ANSI: 2 sd 10:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete sd 10:0:0:0: [sdc] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 38 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 10:0:0:0: [sdc] Assuming drive cache: write through sd 10:0:0:0: [sdc] Attached SCSI disk device label tessier-ashpool devid 1 transid 4882 /dev/sdc1 open /dev/sdd1 failed Cheers, Victor -- 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
Re: [PATCH]btrfs: Update existing btrfs_device for renaming device
Yes, exactly. I'll fix this. Thanks.
Regards,
taruisi
(2010/02/09 14:23), Yang Hongyang wrote:
TARUISI Hiroaki wrote:
This patch updates device name in btrfs device.
We can mount a device if its name are changed.
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
fs/btrfs/volumes.c |7 +++
1 file changed, 7 insertions(+)
Index: b/fs/btrfs/volumes.c
===
--- a/fs/btrfs/volumes.c 2010-02-09 12:11:33.0 +0900
+++ b/fs/btrfs/volumes.c 2010-02-09 12:43:29.0 +0900
@@ -365,6 +365,7 @@ static noinline int device_list_add(cons
struct btrfs_device *device;
struct btrfs_fs_devices *fs_devices;
u64 found_transid = btrfs_super_generation(disk_super);
+char *name;
fs_devices = find_fsid(disk_super-fsid);
if (!fs_devices) {
@@ -411,6 +412,12 @@ static noinline int device_list_add(cons
device-fs_devices = fs_devices;
fs_devices-num_devices++;
+} else if (strcmp(device-name, path)) {
+name = kstrdup(path, GFP_NOFS);
+if (!device-name)
It should be if (!name) here?
+return -ENOMEM;
+kfree(device-name);
+device-name = name;
}
if (found_transid fs_devices-latest_trans) {
(2009/11/08 6:44), Gustavo Alves wrote:
Hi Chris,
I found the same problem on 2.6.32-0.33.rc5.git1 with btrfs-progs
0.19. This problem is already fixed?
Thanks
Gustavo Junior Alves
Specchio Soluções em TI
http://specchio.inf.br
Tel: +55 19 9223-0500
From: Chris Mason chris.mason_ät_oracle.com
Date: Tue, 07 Apr 2009 07:35:56 -0400
On Mon, 2009-04-06 at 18:41 +0100, Hugo Mills wrote:
There seems to be some issue over changing the names of the device
that a btrfs filesystem lives on:
# lvcreate scratch -n fstest -L 2G
Logical volume fstest created
# mkfs -t btrfs /dev/scratch/fstest
WARNING! - Btrfs v0.18-ge3b0f66 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label (null) on /dev/scratch/fs1
nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00GB
Btrfs v0.18-ge3b0f66
# mount /dev/scratch/fstest /mnt
# umount /mnt
# lvrename scratch fstest derek
Renamed fstest to derek in volume group scratch
# mount /dev/scratch/derek /mnt
mount: /dev/mapper/scratch-derek: can't read superblock
# lvrename scratch derek fstest
Renamed derek to fstest in volume group scratch
# mount /dev/scratch/fstest /mnt
[success]
The rename works properly on a completely virgin filesystem, but
not on one that's been mounted and unmounted (as above).
Whoops, we need to reset the pathname when a probe finds a given dev
uuid on a given device. I'll patch it up when I get back next week.
Thanks for this bug report.
-chris
--
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
[PATCH v2]btrfs: Update existing btrfs_device for renaming device
This patch updates device name in btrfs device information.
We can mount a device if its name are changed.
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
fs/btrfs/volumes.c |7 +++
1 file changed, 7 insertions(+)
Index: b/fs/btrfs/volumes.c
===
--- a/fs/btrfs/volumes.c2010-02-09 12:11:33.0 +0900
+++ b/fs/btrfs/volumes.c2010-02-09 13:54:39.0 +0900
@@ -365,6 +365,7 @@ static noinline int device_list_add(cons
struct btrfs_device *device;
struct btrfs_fs_devices *fs_devices;
u64 found_transid = btrfs_super_generation(disk_super);
+ char *name;
fs_devices = find_fsid(disk_super-fsid);
if (!fs_devices) {
@@ -411,6 +412,12 @@ static noinline int device_list_add(cons
device-fs_devices = fs_devices;
fs_devices-num_devices++;
+ } else if (strcmp(device-name, path)) {
+ name = kstrdup(path, GFP_NOFS);
+ if (!name)
+ return -ENOMEM;
+ kfree(device-name);
+ device-name = name;
}
if (found_transid fs_devices-latest_trans) {
(2009/11/08 6:44), Gustavo Alves wrote:
Hi Chris,
I found the same problem on 2.6.32-0.33.rc5.git1 with btrfs-progs
0.19. This problem is already fixed?
Thanks
Gustavo Junior Alves
Specchio Soluções em TI
http://specchio.inf.br
Tel: +55 19 9223-0500
From: Chris Mason chris.mason_ät_oracle.com
Date: Tue, 07 Apr 2009 07:35:56 -0400
On Mon, 2009-04-06 at 18:41 +0100, Hugo Mills wrote:
There seems to be some issue over changing the names of the device
that a btrfs filesystem lives on:
# lvcreate scratch -n fstest -L 2G
Logical volume fstest created
# mkfs -t btrfs /dev/scratch/fstest
WARNING! - Btrfs v0.18-ge3b0f66 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
fs created label (null) on /dev/scratch/fs1
nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00GB
Btrfs v0.18-ge3b0f66
# mount /dev/scratch/fstest /mnt
# umount /mnt
# lvrename scratch fstest derek
Renamed fstest to derek in volume group scratch
# mount /dev/scratch/derek /mnt
mount: /dev/mapper/scratch-derek: can't read superblock
# lvrename scratch derek fstest
Renamed derek to fstest in volume group scratch
# mount /dev/scratch/fstest /mnt
[success]
The rename works properly on a completely virgin filesystem, but
not on one that's been mounted and unmounted (as above).
Whoops, we need to reset the pathname when a probe finds a given dev
uuid on a given device. I'll patch it up when I get back next week.
Thanks for this bug report.
-chris
--
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
Re: [RFC] Move all btrfs command to only one command
Hi Goffredo, It sounds good for me though detailed points need more discussion. btrfs-progs seems unkind for operator as you mentioned, and many features will be implemented to btrfsctl from now, it's good that we arrange and unify btrfs-progs now. As for me, plain keywords(delete,defrag...) as commands are welcome. Regards, taruisi (2010/01/22 4:29), Goffredo Baroncelli wrote: Hi all this RFC is about unify all btrfs command (btrfsctl, btrfs-show, btrfs-tune.. ) in only one called btrfs (or whatever we want). Today btrfsctl needs a bit of care because * the help is basically wrong [1] * the return codes are incoherent [2] * the syntax of the command are very ugly (a lot of people complained about the subvolumes/snapshot creation, because they aren't very clear) [3] * the code is a mess (in the main there is a useless for(); there a lot of 'if' because sometime the last argument is the target of ioctl, sometime no..) [4] * The checks of the number of argument are incorrect [5] I think that is better to rewrite from scratch a new command instead of patching the old one. So we don't care about the backward compatibility. Other filesystem (hammer, tux3, zfs) have only one command for management purpose. Instead we have btrfsctl (which has a lot of different function) and btrfs-show, btrfs-tune, btrfs-volume which have few functions. There are patches which address [6] some of the previous issues, but these are not integrated (because the developers are busy on other issues). To me rewriting from scratch seems a fast path for solving these issues. I made a prototype (see attached file) in bash of what btrfs should be. The major different from btrfsctl are: - I talk about clone and not snapshot - If a sub-volume is required (for example for the cloning), the program check that the argument is a root of the subvolume and not a subdirectory - Creating a sub-volume requires only one argument Below some examples: $ btrfs Usage: btrfs clone|-c source [dest/]name Clone the subvolume source with the name name in the dest directory. btrfs delete|-d subvolume Delete the subvolume subvolume. btrfs create|-C [dest/]name Create a subvolume in dest (or the current directory if not passed. btrfs defrag|-d file|dir [file|dir...] Defragment a file or a directory. btrfs fssync|-s path Force a fs sync on the filesystem path btrfs resize|-r [+/-]newsize[gkm]|max filesystem Resize the file system. If 'max' is passed, the filesystem will occupe all available space on the device. btrfs scan|-S [device [device..] Scan all device for or the passed device for a btrfs filesystem. btrfs show|-l dev|label [dev|label.. ] Show the btrfs devices btrfs balance|-b path Balance teh chunk across the device btrfs add|-A dev path Add a device to a filesystem btrfs rem|-R dev path Remove a device to a filesystem btrfs help|--help|-h Show the help. Comment are welcome [1] In the help the -r, -c options seem that don't need any further argument; The -D command seems that accpet only . as 2nd parameter [2] If something goes wrong btrfsctl returns 1; if the ioctl return 0 the command still returns 1... [3] See the email in the mailing list [4] If I does btrfsctl -c -d -A -S a . what result do you aspect ? [5] If I pass more argument than the ones needed no error is showed. -D checks if there is only one argument, when it needs two argument... [6] - 10/26/09 - little fixme in btrfsctl.c [PATCH] - From: David Nicol davidni...@gmail.com - 12/24/09 - [PATCH] btrfs-progs: check slash in deleting subvolumes. - From: TARUISI - 12/13/09 - [PATCH] Improve the btrfsctl help - From: Goffredo Baroncelli kreij...@gmail.com -- 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: snapshots of directories
Yes. I mean that. In detail, 'non subvolume directory' may be more precise than 'arbitrary directory'. Thanks for your description. Regards, taruisi (2010/01/14 4:04), Andrey Kuzmin wrote: Did I get you right in that btrfs does not support snapshots of an arbitrary directory? Regards, Andrey On Tue, Jan 12, 2010 at 5:19 AM, TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com wrote: In btrfs, snapshot is a clone of subvolume, not arbitrary directory. You specified '/root' directory and it is not subvolume, snapshot is created for parent subvolume, root of filesystem. Regards, taruisi (2010/01/12 11:12), Michael Niederle wrote: I try to take a snapshot of a single directory, e.g. root: btrfsctl -s root.2010-01-12 /root operation complete Btrfs v0.19-4-gab8fb4c-dirty Then I take look what's inside the newly created snapshot: ls -l /root.2010-01-12/ total 0 drwxr-xr-x 1 root root 1192 2010-01-03 20:32:12 bin drwxr-xr-x 1 root root 76 2009-06-25 0:40:35 boot drwxr-xr-x 1 root root 1756 2010-01-12 2:33:07 cmds drwxr-xr-x 1 root root0 2010-01-06 12:21:46 data drwxr-xr-x 1 root root 4356 2010-01-12 2:07:00 dev drwxr-xr-x 1 root root 42 2010-01-04 12:29:45 downloads drwxr-xr-x 1 root root 4528 2010-01-12 2:12:12 etc drwxr-xr-x 1 root root 52 2010-01-11 12:57:47 home drwxr-xr-x 1 root root0 2007-11-10 4:44:07 initrd drwxr-xr-x 1 root root 4490 2010-01-05 20:15:53 lib drwxr-xr-x 1 root root 124 2008-04-27 14:53:39 mnt drwxr-xr-x 1 root root 62 2008-01-08 0:21:58 net drwxr-xr-x 1 root root0 2008-04-09 3:19:16 objects drwxr-xr-x 1 root root 316 2009-12-28 23:23:13 opt dr-xr-xr-x 1 root root0 2007-11-10 3:35:28 proc drwxr-xr-x 1 root root 7676 2010-01-11 0:35:41 root drwxr-xr-x 1 root root0 2010-01-12 1:56:17 save drwxr-xr-x 1 root root0 2010-01-12 1:55:58 save2 drwxr-xr-x 1 root root 3804 2010-01-06 2:36:08 sbin drwxr-xr-x 1 root root0 2007-11-10 3:35:28 sys drwxr-xr-x 1 root root 358 2010-01-11 18:44:29 tmp drwxr-xr-x 1 root root 176 2009-12-29 17:08:37 usr drwxr-xr-x 1 root root 72 2010-01-05 20:03:00 var It seems that always a snapshot of the root is taken instead one of the specified directory? Is this by design? Snapshotting the root works fine, but if you take several snapshots it's a bit recursive, because every new snapshot contains all previous snapshots. Greetings, Michael -- 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 -- 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
Re: snapshot/subvolume removal
Yes, it's not enough reliable for all users, and it may be possible, but disk format may be the last point to change. If we want to change it, we need to discuss its necessity carefully and implement it [almost] without incompatibility. Regards, taruisi (2010/01/12 16:08), Piavlo wrote: TARUISI Hiroaki wrote: Thanks for your comment. I think your request is reasonable but because there's no information about a hierachy of snapshots in filesystem, we cannot know it for now. In future, these information may be supplied by application programs which manage all snapshots or backups. Maintaining snapshot hierarchy by external application is not reliable and error prone compared to maintaining it withing the btrfs itself, probably by adding the parent treeid field for every shapshot/subvolume. Thanks Alex -- 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: snapshot/subvolume removal
Thanks for your comment. I think your request is reasonable but because there's no information about a hierachy of snapshots in filesystem, we cannot know it for now. In future, these information may be supplied by application programs which manage all snapshots or backups. Regards, taruisi (2010/01/10 07:01), Piavlo wrote: TARUISI Hiroaki wrote: For now, subvolumes and snapshots look like just directories. If you want to distinguish them, there's only an unusual way, that is, analyzing with btrfs-debug-tree. I posted patches for listing snapshots/subvolumes two months ago, and Josef Bacik posted its bugfix patch. This feature may be delivered in sooner or later. If you want to try it now, check these URLs. http://patchwork.kernel.org/patch/60923/raw/ http://patchwork.kernel.org/patch/60920/raw/ http://patchwork.kernel.org/patch/67332/raw/ Thanks for pointing me all the needed patched, the btrfsctl -l is working for me fine. Patches and requests are welcome. Currently btrfsctl -l show only which directories are snapshots/subvolumes, it would be nice if it would also show a hierarchy of snapshots i.e. from which subvolume/snapshot a specific snapshot was taken from. For example: / # cd /.btrfs /.btrfs # btrfsctl -l /.btrfs Base path = /.btrfs/ No. Tree ID Subvolume Relative Path 1 275 rootfs-old/ 2 277 rootfs/ operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -S subvol0 . operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -l /.btrfs/ Base path = /.btrfs/ No. Tree ID Subvolume Relative Path 1 275 rootfs-old/ 2 277 rootfs/ 3 279 subvol0/ operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -s subvol0-snap subvol0 operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -s subvol0/subvol1-snap subvol0 operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -s subvol1-snap-snap subvol0/subvol1-snap operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -l /.btrfs/ Base path = /.btrfs/ No. Tree ID Subvolume Relative Path 1 275 rootfs-old/ 2 277 rootfs/ 3 279 subvol0/ 4 281 subvol0/subvol1-snap/ 5 280 subvol0-snap/ 6 282 subvol1-snap-snap/ operation complete Btrfs v0.19-4-gab8fb4c-dirty / .btrfs # It would be nice if it would possible to show the youngest snapshot ancestor - something like this: /.btrfs # btrfsctl -l /.btrfs/ Base path = /.btrfs/ No. Tree ID Subvolume Relative Path Snapshot Ancestor 1 275 rootfs-old/ none 2 277 rootfs/ rootfs-old/ 3 279 subvol0/ none 4 281 subvol0/subvol1-snap/subvol0/ 5 280 subvol0-snap/ subvol0/ 6 282 subvol1-snap-snap/ subvol0/subvol1-snap/ operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -D subvol1-snap subvol0 operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -l . Base path = /.btrfs/ No. Tree ID Subvolume Relative PathSnapshot Ancestor 1 275 rootfs-old/none 2 277 rootfs/ rootfs-old/ 3 279 subvol0/none 4 280 subvol0-snap/ subvol0/ 5 282 subvol1-snap-snap/ subvol0/ operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -D subvol0 . operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # btrfsctl -l . Base path = /.btrfs/ No. Tree ID Subvolume Relative Path Snapshot Origin 1 275 rootfs-old/ none 2 277 rootfs/ rootfs-old/ 3 280 subvol0-snap/none 4 282 subvol1-snap-snap/none operation complete Btrfs v0.19-4-gab8fb4c-dirty /.btrfs # Thanks Alex -- 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: snapshot/subvolume removal
Thanks for reply and changing. I planned one more patch to list up all subvolumes under fs tree. This must be useful in case of mounting with subvol parameter. Regards, taruisi (2010/01/11 5:18), Chris Mason wrote: On Fri, Jan 08, 2010 at 05:28:42PM +0900, TARUISI Hiroaki wrote: For now, subvolumes and snapshots look like just directories. If you want to distinguish them, there's only an unusual way, that is, analyzing with btrfs-debug-tree. I posted patches for listing snapshots/subvolumes two months ago, and Josef Bacik posted its bugfix patch. This feature may be delivered in sooner or later. If you want to try it now, check these URLs. http://patchwork.kernel.org/patch/60923/raw/ http://patchwork.kernel.org/patch/60920/raw/ http://patchwork.kernel.org/patch/67332/raw/ Patches and requests are welcome. Thanks again for the subvolume listing patch, it's going to be a great feature. I'm afraid I've had to make some small changes. ioctls have some very strict rules for the arguments, and pointers and list heads should not be passed in ioctl structs. We also need to change the patch to make the ioct args struct the same size on both 32 bit and 64 bit machines, which usually just means aligning and padding the fields as required. I have started on this and hope to finish it on Tuesday. But if you have any additions to the patch please let me know. -chris -- 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: snapshot/subvolume removal
For now, subvolumes and snapshots look like just directories. If you want to distinguish them, there's only an unusual way, that is, analyzing with btrfs-debug-tree. I posted patches for listing snapshots/subvolumes two months ago, and Josef Bacik posted its bugfix patch. This feature may be delivered in sooner or later. If you want to try it now, check these URLs. http://patchwork.kernel.org/patch/60923/raw/ http://patchwork.kernel.org/patch/60920/raw/ http://patchwork.kernel.org/patch/67332/raw/ Patches and requests are welcome. Regards, taruisi (2010/01/06 17:33), Piavlo wrote: TARUISI Hiroaki wrote: Hi, We can delete snapshot with btrfsctl -D . It's available for your btrfs-progs version. -D works great Also how can I know if some directory is subvolume or snapshot or just a normal directory? Is there a way to list all the existing snapshots subvolumes under btrfs? Thanks Alex -- 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
Re: btrfs-progs: New utility to swap subvolumes
Thanks for your greetings. I read your article, and could follow your idea, which looks very practical rule to me. But we may need some application which support to create or maintain these rules because the relation mount point and subvolumes and snapshots gets complicated as number of subvolumes increases. Regards, taruisi (2010/01/05 2:20), Goffredo Baroncelli wrote: On Monday 04 January 2010, TARUISI Hiroaki wrote: Buon anno, Goffredo. あけまして おめでとう Taruisi, (I hope that happy new year is correctly written) Taking snapshot in btrfs is very easy, but handling snapshots is very confusing. So, we must make a rule of snapshotting such as your proposal, which seems to me very good and useful. If rules like this are forced regardless of operator's preference, this utility may become a deadwood. I detailed this idea in this article http://kreijack.blogspot.com/2010/01/linux-btrfs-example-of-layout.html BR G.Baroncelli -- 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
Re: snapshot/subvolume removal
Hi, We can delete snapshot with btrfsctl -D . It's available for your btrfs-progs version. And parameters of btrfsctl -s/S are not coherent at the last argument. In creating snapshots, the last argument implies the directory where subvolume is to be created, but in taking snapshots, the last argument implies subvolume we take snapshot of, and snapshots are created under current directory. So, shell btrfsctl -s rsync-snap rsync operation complete snapshot rsync-snap is created under current directory, and, Btrfs v0.19-4-gab8fb4c-dirty shell btrfsctl -S rsync-snap rsync operation complete subvolume rsync-snap is created under rsync directory in current directory. They are created under different directories. Regards, taruisi (2010/01/06 6:18), Piavlo wrote: Hi, Does btrfs support snapshot or/and subvolume removal ? If yes how, since I could not find the commands to do that? If not is there any estimation when this feature will be available? Is there a tool to list the existing subvolumes/snapshots? It looks like the snapshots can overridden by subvolumes, see below: shell btrfsctl -s rsync-snap rsync operation complete Btrfs v0.19-4-gab8fb4c-dirty shell btrfsctl -S rsync-snap rsync operation complete Btrfs v0.19-4-gab8fb4c-dirty shell btrfsctl -s rsync-snap rsync ioctl:: File exists shell Is that expected? What happens to the snapshot then it is overridden by subvolume? It does not seem reasonable that snapshot can be converted into subvolume, since newly created subvolume holds no data ,while the snapshot is a snapshot of other previously existing subvolume and holds data. So is snapshots simply destroyed prior to subvolume creation, in the above scenario? Thanks Alex -- 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
Re: btrfsctl exit with 1 when succeed
Thank you, I don't think of a devices scan. After all, I wonder why. Return codes must be coherent so that we can know good from no-good by them. In this spec, it's very hard to make shell scripts with btrfsctl. If there isn't good reason, we need to fix it, I think. (2009/12/25 18:25), Goffredo Baroncelli wrote: On Friday 25 December 2009, TARUISI Hiroaki wrote: I also want to know why this conversion is needed. This might be a typo, I think. Could someone tell us why? Can we fix this conversion? Or shouldn't we fix it considering back-compatibility? It is even worse: the result code returned by btrfsctl is not coherent. btrfsctl returns always 1 except: - after a devices scan (in this case the result is _always_ 0) - if the ioctl returns a value greater than 0 In other all cases (error in the command line, the device btrfs-control doesn't exists, error in opening a file) the return code is 1. That doesn't permit to differentiate an error from a good return. BR Goffredo Regards, taruisi (2009/11/11 15:16), Gong, Zhipeng wrote: We'd like to use btrfsctl in a shell script, however, btrfsctl exit with 1 even if the operation is successful, which is opposite to the usual shell command convention. Why btrfsctl add this conversion in the end? if (ret) exit(0); else exit(1); Thanks Zhipeng -- 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 -- 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
Re: btrfs-progs: New utility to swap subvolumes
Thank you for your mail. I intended to create a swap utility including root subvolume. That was the goal. Swapping root subvolume is not implemented yet... For now, as you say, in some cases this utility does simple mv commands, but in some cases, it has some advantages. We can swap subvolumes regardless of mounted-subvolume. (only when we mount other subvolume than fs tree) And, because we can identify snapshot (its date or target subvol) with subvolume ID, it is suitable to swap with ID. Regards, taruisi (2009/12/28 5:23), Goffredo Baroncelli wrote: On Thursday 24 December 2009, TARUISI Hiroaki wrote: New utility(btrfsrevert) added to swap subvolumes. With this utility, a subvolume (Source Subvolume) takes place of another subvolume (Target Subvolume), and target subvolume goes under hidden directory(.old_trees) in filesystem root(fs tree, tree id=5), and its name is expanded with random UUID. Hi Taruisi, which is the supposed goal of this program ? If I understand correctly btrfsrevert renames subvolumes. But we can rename a subvolume using the mv command. So btrfsrevert may be simulated with a couple of 'mv' command: # btrfsrevert -s vola-id -t volb-id /dev/sdX is equivalent to # mount /dev/sdX/ /mnt# only needed if the filesystem is un-mounted # mkdir /mnt/.old_trees # mv /mnt/volb /mnt/.old_trees/volb.random-number # mv /mnt/vola /mnt/volb # umount /mnt Is right ? And moreover btrfsrevert has the limit that the file-system shall not be mounted... On the plus side of btrfsrevert, I can swap volumes without having the btrfs module loaded ... BR G.Baroncelli This utility cannot operate mounted filesystem. This is only for unmounted device. And this utility also cannot operate filesystem root. For now, if we want to swap filesystem root, we can use btrfsctl with Josef Bacik's patch. I wonder which is better, integrating 'root swap' ioctl or not supporting 'root swap' as for this utility... A patch follows this mail. man-page-like description and examples are as follows. NAME btrfsrevert - swap subvolumes. SYNOPSIS btrfsrevert -s source_subvolume -t target_subvolume device OPTIONS -s source subvolume Specify subvolume number which replace target subvolume. -t target subvolume Specify subvolume number which is replaced by source subvolume. device Specify target device which is not mounted. SAMPLES Consider two subvolumes 'target'(id=256) and 'source'(id=300) exist in filesystem root. / + +- 'target' (id=256) +- 'source' (id=300) In this case, following command swaps subvolume, # btrfsrevert -s 300 -t 256 /dev/hda1 like this. / + +- 'target' (id=300) | +- '.old_tree' +- 'target_[random uuid]' (id=256) A subvolume(id:256) is replaced with a subvolume(id:300), and replaced subvolume(id:256) goes to .old_trees directory. Regards, 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 -- 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
Re: btrfsctl exit with 1 when succeed
I also want to know why this conversion is needed. This might be a typo, I think. Could someone tell us why? Can we fix this conversion? Or shouldn't we fix it considering back-compatibility? Regards, taruisi (2009/11/11 15:16), Gong, Zhipeng wrote: We'd like to use btrfsctl in a shell script, however, btrfsctl exit with 1 even if the operation is successful, which is opposite to the usual shell command convention. Why btrfsctl add this conversion in the end? if (ret) exit(0); else exit(1); Thanks Zhipeng -- 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
[PATCH] btrfs-progs: check slash in deleting subvolumes.
For now, btrfsctl does not check whether subvolume name contains slash
or not. If someone specify subvolume with trailing slash (in case
using shell completion), ioctl returns with EINVAL and this error
may confuse some careless users like me. So, this patch adds check
slashes in subvolume name in deletion same as snapshot/subvolume
creating. But considering shell completion, this fix allows trailing
slash.
Regards,
taruisi
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
btrfsctl.c | 11 +++
1 file changed, 11 insertions(+)
Index: b/btrfsctl.c
===
--- a/btrfsctl.c2009-12-24 11:40:15.0 +0900
+++ b/btrfsctl.c2009-12-24 11:38:51.0 +0900
@@ -266,6 +266,7 @@ int main(int ac, char **av)
unsigned long command = 0;
int len;
char *fullpath;
+ char *pos;
if (ac == 2 strcmp(av[1], -a) == 0) {
fprintf(stderr, Scanning for Btrfs filesystems\n);
@@ -332,6 +333,16 @@ int main(int ac, char **av)
command = BTRFS_IOC_SNAP_DESTROY;
name = av[i + 1];
len = strlen(name);
+ pos = strchr(name, '/');
+ if (pos) {
+ if (*(pos + 1) == '\0')
+ *(pos) = '\0';
+ else {
+ fprintf(stderr,
+ error: / not allowed in
names\n);
+ exit(1);
+ }
+ }
if (len == 0 || len = BTRFS_VOL_NAME_MAX) {
fprintf(stderr, -D size too long\n);
exit(1);
--
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: BUG: Link from sub volume, then remove the subvolume - wrong link
Hi, I think message:'Operation not permitted' is more proper for this problem than 'Invalid cross-device link' simply because this link is not cross-device link. Of course, this operation is prohibited not by security policy but by inner limitation of btrfs, this usage of EPERM may be a kind of abuses... Regards, taruisi (2009/12/15 3:43), Andrew Lutomirski wrote: [cc: Chris -- This, or something like it, should probably go to stable, but it needs to make it to upstream somewhere first.] On Sun, Dec 13, 2009 at 6:42 PM, TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com wrote: Hi, We can see the patch in ML archive or at 'Patchwork' site. http://patchwork.kernel.org/patch/59519/ That fixes the bug, but shouldn't the error be EXDEV? It has nothing to do with permissions. --Andy -- 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
Re: [PATCH] Btrfs: fix various things with the listing ioctl
(2009/12/15 4:17), Josef Bacik wrote:
With slab poisoning on you could panic the box simply by running btrfsctl -l
multiple times in a row on the same volume. This patch fixes up the ioctl
stuff
to be a bit cleaner, makes sure we always call btrfs_free_path() instead of
kfree(path) and make sure we do not kfree() our work names before we are done
using them. There were several memory leaks and use after free problems
previously, they appear to be gone now, and as an added bonus doing btrfsctl
-l
no longer panic's the box. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
Thank you for your patch. I've tested this patch and
I found it works. And I'd like to add one line to
prevent from another tiny leak.
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
fs/btrfs/ioctl.c |1 +
1 file changed, 1 insertion(+)
Index: b/fs/btrfs/ioctl.c
===
--- a/fs/btrfs/ioctl.c 2009-12-15 11:31:18.0 +0900
+++ b/fs/btrfs/ioctl.c 2009-12-15 11:33:28.0 +0900
@@ -989,6 +989,7 @@ static noinline int btrfs_ioctl_snap_lis
if (rest sizeof(struct btrfs_ioctl_subvol_items) +
name_len + strlen(work_path) + 1) {
svol-next_len = name_len + strlen(work_path);
+ kfree(name);
if (copy_to_user(arg, svol, sizeof(*svol))) {
ret = -EFAULT;
goto out;
--
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: BUG: Link from sub volume, then remove the subvolume - wrong link
Hi, We can see the patch in ML archive or at 'Patchwork' site. http://patchwork.kernel.org/patch/59519/ Thanks, taruisi (2009/12/13 3:39), Andy Lutomirski wrote: TARUISI Hiroaki wrote: Hi, I don't know how a hard link becomes to a soft link, hard link across subvolumes should not allowed in btrfs. Hard link contains target inode number but not target tree. So, if we can create such hard link normally, it points to a file which has same inode number in same subvolume. As for this problem, Christian Parpart posted a patch, and I rebased it. Can you post a link? I'd like to test it, and it should probably go into -stable (since it fixes an oops that can be triggered without privileges). Thanks, Andy -- 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
Re: [PATCH] Btrfs: change how we mount subvolumes
Hi,
When I made snapshot listing, I thought 'subvol' parameter
is not enough as G.Baroncelli wrote. I think nice feature too.
(I tried to expand subvol parameter feature, by iterating
dentry search(lookup_one_len) but I cannot treat dentries
correctly yet. :)
But, is 'subvol=name' not prohibited yet? When I specified
'subvol=name', mount command simply mounts filesystem root
without error.
Josef Bacik wrote:
This work is in preperation for being able to set a different root as the
default mounting root.
There is currently a problem with how we mount subvolumes. We cannot
currently
mount a subvolume of a subvolume, you can only mount subvolumes/snapshots of
the
default subvolume. So say you take a snapshot of the default subvolume and
call
it snap1, and then take a snapshot of snap1 and call it snap2, so now you have
/
/snap1
/snap1/snap2
as your available volumes. Currently you can only mount / and /snap1, you
cannot mount /snap1/snap2. To fix this problem instead of passing
subvol=name
you must pass in subvol=treeid, where treeid is the tree id that gets spit
out via the subvolume listing you get from the subvolume listing patches
(btrfsctl -l). This allows us to mount /, /snap1 and /snap1/snap2 as the root
volume.
In addition to the above, we also now read the default dir item in the tree
root
to get the root key that it points to. For now this just points at what has
always been the default subvolme, but later on I plan to change it to point at
whatever root you want to be the new default root, so you can just set the
default mount and not have to mount with -o subvol=treeid. I tested this
out
with the above scenario and it worked perfectly. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/export.c |4 +-
fs/btrfs/inode.c | 10 ++-
fs/btrfs/relocation.c |2 +-
fs/btrfs/super.c | 167 +++-
fs/btrfs/tree-log.c |2 +-
6 files changed, 133 insertions(+), 54 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 444b3e9..464f688 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2318,7 +2318,7 @@ int btrfs_init_cachep(void);
void btrfs_destroy_cachep(void);
long btrfs_ioctl_trans_end(struct file *file);
struct inode *btrfs_iget(struct super_block *s, struct btrfs_key *location,
- struct btrfs_root *root);
+ struct btrfs_root *root, int *was_new);
int btrfs_commit_write(struct file *file, struct page *page,
unsigned from, unsigned to);
struct extent_map *btrfs_get_extent(struct inode *inode, struct page *page,
diff --git a/fs/btrfs/export.c b/fs/btrfs/export.c
index ba5c3fd..951ef09 100644
--- a/fs/btrfs/export.c
+++ b/fs/btrfs/export.c
@@ -95,7 +95,7 @@ static struct dentry *btrfs_get_dentry(struct super_block
*sb, u64 objectid,
btrfs_set_key_type(key, BTRFS_INODE_ITEM_KEY);
key.offset = 0;
- inode = btrfs_iget(sb, key, root);
+ inode = btrfs_iget(sb, key, root, NULL);
if (IS_ERR(inode)) {
err = PTR_ERR(inode);
goto fail;
@@ -223,7 +223,7 @@ static struct dentry *btrfs_get_parent(struct dentry
*child)
key.type = BTRFS_INODE_ITEM_KEY;
key.offset = 0;
- dentry = d_obtain_alias(btrfs_iget(root-fs_info-sb, key, root));
+ dentry = d_obtain_alias(btrfs_iget(root-fs_info-sb, key, root,
NULL));
if (!IS_ERR(dentry))
dentry-d_op = btrfs_dentry_operations;
return dentry;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b3ad168..b383e53 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2131,7 +2131,7 @@ void btrfs_orphan_cleanup(struct btrfs_root *root)
found_key.objectid = found_key.offset;
found_key.type = BTRFS_INODE_ITEM_KEY;
found_key.offset = 0;
- inode = btrfs_iget(root-fs_info-sb, found_key, root);
+ inode = btrfs_iget(root-fs_info-sb, found_key, root, NULL);
if (IS_ERR(inode))
break;
@@ -3609,7 +3609,7 @@ static struct inode *btrfs_iget_locked(struct
super_block *s,
* Returns in *is_new if the inode was read from disk
*/
struct inode *btrfs_iget(struct super_block *s, struct btrfs_key *location,
- struct btrfs_root *root)
+ struct btrfs_root *root, int *new)
{
struct inode *inode;
@@ -3624,6 +3624,8 @@ struct inode *btrfs_iget(struct super_block *s, struct
btrfs_key *location,
inode_tree_add(inode);
unlock_new_inode(inode);
+ if (new)
+ *new = 1;
}
return inode;
@@ -3676,7 +3678,7 @@ struct inode *btrfs_lookup_dentry(struct inode *dir,
struct dentry *dentry)
return NULL;
if (location.type
Re: [RFC] Btrfs: add ioctl to set the default mount subvol
Hi, Josef.
Thank you for your considering listing patch.
For now, snapshot listing starts with mounted directory,
but I thought listing by subvol id is needed, considering
'subvol' option (and now, your patch).
I made a 'subvol id' patch, but if you have another idea,
could you tell me?
Regards,
taruisi
Josef Bacik wrote:
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 just done some superficial testing on this, but it
works well enough. It breaks the snapshot listing thing so don't try and use
that with this patch, I will fix that later, I just want to run this by
everybody to make sure this is what we want. 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
--
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
Re: Q: list btrfs snapshots/subvolumes
Some questions: * how do I list available snapshots/subvolumes? As for this question, we will soon be able to list available snapshots/subvolumes with btrfsctl utility. But for now, we should count number of BTRFS_ROOT_ITEMs with btrfs-debug-tree or so. Regards, 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
Re: Unable to mount loopback devices in RAID mode
Yes. 'device' options work good on boot. (There may be trivial differences, perhaps.) Both 'btrfsctl -a|A' and device option of mount calls a same device collection function, 'scan_one_device' and by this function btrfs knows devices for btrfs. # But, there's no mount option like 'btrfsctl -a', so # option string grows longer and longer as number of # devices increases... Leszek Ciesielski wrote: On Tue, Dec 1, 2009 at 6:56 AM, TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com wrote: Btrfs collects block device information when mount or mkfs (device_list_add in volumes.c), and know devid-device relation by collected information. So, if we make filesystem on plain file, btrfs cannot know devid-device relation. As a result, btrfs cannot know which is 'devid=n', and mount fails. Same as this, if collected relation is cleared by shutdown, mount fails. If wlee need to mount a filesystem without fail(cf, /etc/fstab line), we should specify 'device' options for every devices(except mount target device) like this. # mount -t btrfs -o device=/dev/loop2,device=/dev/loop3, device=/dev/loop4 /dev/loop1 /mnt/ (when a filesystem is constructed by /dev/loop[1-4]) Regards, taruisi Would this option [mount -t btrfs -o device=/dev/sdb2 /dev/sda2 /mnt] work on boot, bypasing the need for btrfsctl -a to mount a multi-device filesystem? -- 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
Re: Unable to mount loopback devices in RAID mode
Hi, It seems to me this error is caused by device control policy of btrfs, not mkfs. This error occures not only on loopback devices, but also on normal block devices (with one difference in procedure). # mkfs.btrfs -m raid1 -d raid1 /dev/hdc1 /dev/hdc2 # reboot (- This is a difference.) (after reboot) # mount -t btrfs /dev/hdc1 /mnt/ mount: wrong fs type, bad option, bad superblock on /dev/hdc1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Otherwise, when you do losetup before mkfs, it works even if loopback devices. # dd ~~~ (create files) # losetup /dev/loop1 img1 # losetup /dev/loop2 img2 # mkfs.btrfs -m raid1 -d raid1 /dev/loop1 /dev/loop2 # mount -t btrfs /dev/loop1 /mnt/ (- OK) Btrfs collects block device information when mount or mkfs (device_list_add in volumes.c), and know devid-device relation by collected information. So, if we make filesystem on plain file, btrfs cannot know devid-device relation. As a result, btrfs cannot know which is 'devid=n', and mount fails. Same as this, if collected relation is cleared by shutdown, mount fails. If we need to mount a filesystem without fail(cf, /etc/fstab line), we should specify 'device' options for every devices(except mount target device) like this. # mount -t btrfs -o device=/dev/loop2,device=/dev/loop3, device=/dev/loop4 /dev/loop1 /mnt/ (when a filesystem is constructed by /dev/loop[1-4]) Regards, taruisi Andi Drebes wrote: Hi! So I do not understand why it does not work correctly for him to mount either device. Maybe this problem is not what I see in my testing (using 32) with disk partitions instead of loop. With partitions, I only see the mount problem on raid0, not on raid1. Without having looked at the code: It seems as if this is a problem in mkfs. The first time, I mount the fresh image I have to search the correct device. After having mounted it at least once, I can use both devices interchangeably: $ dd if=/dev/zero of=raid1_0.img bs=1M count=500 $ dd if=/dev/zero of=raid1_1.img bs=1M count=500 $ mkfs.btrfs -m raid1 -d raid1 raid1_0.img raid1_1.img $ losetup /dev/loop0 raid1_0.img $ losetup /dev/loop1 raid1_1.img $ mount -t btrfs /dev/loop0 /mnt/btrfs mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so $ mount -t btrfs /dev/loop1 /mnt/btrfs #OK $ umount /mnt/btrfs $ mount -t btrfs -o ro /dev/loop0 /mnt/btrfs #OK $ umount /mnt/btrfs $ mount -t btrfs -o ro /dev/loop1 /mnt/btrfs #OK So my guess is, that there's something wrong with mkfs. Cheers, Andi -- 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
Re: [PATCH] Snapshot/subvolume listing feature
Patches for Snapshot/subvolume listing feature are modified. With these patches, ioctl searches for subvolumes under only one tree, and btrfsctl repeatedly creates parameters and calls ioctl until all subvolumes are listed. An intrenal logic was changed but user interfaces (option and contents of a list) remain same as a patch I posted before. Regards, taruisi TARUISI Hiroaki wrote: Thank you for your advice. I'm aware of redundant search, but I didn't think of getdents like interface. I'll remake it without redundant search. Regards, taruisi Yan, Zheng wrote: 2009/11/16 TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com: I made Snapshot/subvolume listing feature. This feature consists of two patches, for kernel(ioctl), and for progs(btrfsctl). I send these two patches as response of this mail soon. New option '-l' is introduced to btrfsctl for listing. If this option is specified, btrfsctl call new ioctl. New ioctl searches root tree and enumerates subtrees. For each subtrees, ioctl searches directory path to tree root, and enumerates more descendant until no more subtree is found. MANPAGE-like option description and examples are as follows. OPTIONS -l _file_ List all snapshot/subvolume directories under a tree which _file_ belongs to. EXAMPLES # btrfsctl -l /work/btrfs Base path = /work/btrfs/ No.Tree ID Subvolume Relative Path 1 256 ss1/ 2 257 ss2/ 3 258 svs1/ss1/ 4 259 svs1/ss2/ 5 260 svs2/ss1/ 6 261 svs2/ss2/ 7 262 ss3/ 8 263 ss4/ 9 264 sv_pool/ 10 265 sv_pool/ss01/ 11 266 sv_pool/ss02/ 12 267 sv_pool/ss03/ 13 268 sv_pool/ss04/ 14 269 sv_pool/ss05/ 15 270 sv_pool/ss06/ 16 271 sv_pool/ss07/ 17 272 sv_pool/ss08/ 18 273 sv_pool/ss09/ 19 274 sv_pool/ss10/ operation complete Btrfs v0.19-9-gd67dad2 Thank you for doing this. I have a quick look at the patches. It seems the ioctl returns full path to each subvolume and uses sequence ID to indicate the progress of listing. Every time the ioctl is called, it tries building full list of subvolume, then skip entries that already returned. I think the API is suboptimal, a getdents like API is better. (The ioctl only lists subvolumes within a given subvolume, the user program call the ioctl recursively to list all subvolumes.) Yan, Zheng -- 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 -- 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] Subvolume listing feature for ioctl.
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(+)
Index: b/fs/btrfs/ioctl.c
===
--- a/fs/btrfs/ioctl.c 2009-11-12 23:47:05.0 +0900
+++ b/fs/btrfs/ioctl.c 2009-11-18 13:51:05.0 +0900
@@ -48,6 +48,7 @@
#include print-tree.h
#include volumes.h
#include locking.h
+#include ctree.h
/* Mask out flags that are inappropriate for the given type of inode. */
static inline __u32 btrfs_mask_flags(umode_t mode, __u32 flags)
@@ -738,6 +739,286 @@ out:
return ret;
}
+/*
+ Search INODE_REFs to identify path name of 'dirid' directory
+ in a 'tree_id' tree. and sets path name to 'name'.
+*/
+static noinline int btrfs_search_path_in_tree(struct btrfs_fs_info *info,
+ u64 tree_id, u64 dirid, char *name)
+{
+ struct btrfs_root *root;
+ struct btrfs_key key;
+ char *name_stack, *ptr;
+ int ret = -1;
+ int slot;
+ int len;
+ int total_len = 0;
+ struct btrfs_inode_ref *iref;
+ struct extent_buffer *l;
+ struct btrfs_path *path;
+
+ if (dirid == BTRFS_FIRST_FREE_OBJECTID) {
+ name[0]='\0';
+ ret = 0;
+ goto out_direct;
+ }
+
+ path = btrfs_alloc_path();
+ name_stack = kzalloc(BTRFS_PATH_NAME_MAX+1, GFP_NOFS);
+ ptr = name_stack[BTRFS_PATH_NAME_MAX];
+
+ key.objectid = tree_id;
+ key.type = BTRFS_ROOT_ITEM_KEY;
+ key.offset = (u64)-1;
+ root = btrfs_read_fs_root_no_name(info, key);
+
+ key.objectid = dirid;
+ key.type = BTRFS_INODE_REF_KEY;
+ key.offset = 0;
+
+ while(1) {
+ ret = btrfs_search_slot(NULL, root, key, path, 0, 0);
+ if (ret0)
+ goto out;
+
+ l = path-nodes[0];
+ slot = path-slots[0];
+ btrfs_item_key_to_cpu(l, key, slot);
+
+ if (ret0 (key.objectid != dirid ||
+ key.type != BTRFS_INODE_REF_KEY))
+ goto out;
+
+ iref = btrfs_item_ptr(l, slot, struct btrfs_inode_ref);
+ len = btrfs_inode_ref_name_len(l, iref);
+ ptr -= len + 1;
+ total_len += len + 1;
+ if (ptr name_stack)
+ goto out;
+
+ *(ptr + len) = '/';
+ read_extent_buffer(l, ptr,(unsigned long)(iref + 1), len);
+
+ if (key.offset == BTRFS_FIRST_FREE_OBJECTID)
+ break;
+
+ btrfs_release_path(root, path);
+ key.objectid = key.offset;
+ key.offset = 0;
+ dirid = key.objectid;
+
+ }
+ if (ptr name_stack)
+ goto out;
+ strncpy(name, ptr, total_len);
+ name[total_len]='\0';
+ ret = 0;
+out:
+ btrfs_release_path(root, path);
+ kfree(path);
+ kfree(name_stack);
+
+out_direct:
+ return ret;
+}
+
+static inline char *btrfs_path_ptr(struct btrfs_ioctl_subvol_leaf *l,
+ int nr)
+{
+ return ((char *)l+l-items[nr].path_offset);
+}
+
+/*
+ Helper function to search tree root directory which contains
+ specified dentry.
+ This function is used in btrfs_ioctl_snap_listing function,
+ to notify root directory(different from the directory what
+ user specified) to user.
+*/
+static noinline struct dentry *btrfs_walkup_dentry_to_root(struct dentry *d)
+{
+ u64 ino;
+ struct dentry *dent = d;
+
+ ino = dent-d_inode-i_ino;
+ while (ino != BTRFS_FIRST_FREE_OBJECTID) {
+ dent = dent-d_parent;
+ ino = dent-d_inode-i_ino;
+ }
+ return dent;
+}
+
+/*
+ Create a list of Snapshot/Subvolume in specified tree.
+ Target tree is specified by struct file.
+*/
+static noinline int btrfs_ioctl_snap_listing(struct file *file,
+void __user *arg)
+{
+ struct btrfs_ioctl_subvol_leaf *leaf;
+ struct btrfs_ioctl_subvol_args *svol;
+ int rest, offset, idx, name_len, i;
+ struct btrfs_root *tree_root;
+ struct btrfs_root_ref *ref;
+ struct extent_buffer *l;
+ struct btrfs_path *path = NULL;
+ struct btrfs_key key;
+ u64 dirid;
+ char *work_path, *f_path, *name;
+ int err, ret = 0, slot = 0;
+ LIST_HEAD(pending_subvols);
+ struct path vfs_path;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ path = btrfs_alloc_path();
+ if (!path)
+ return -ENOMEM;
+
+ work_path = kzalloc(BTRFS_PATH_NAME_MAX + 1, GFP_NOFS);
+ if (!work_path
[PATCH] Subvolume listing feature for btrfsctl.
New feature to list up subvolume/snapshots under
specified tree of file is introduced to btrfsctl.
This patch should apply with corresponding patch
for kernel.
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
btrfsctl.c | 191 +
ioctl.h| 32 ++
2 files changed, 223 insertions(+)
Index: b/btrfsctl.c
===
--- a/btrfsctl.c2009-11-16 11:18:57.0 +0900
+++ b/btrfsctl.c2009-11-18 12:09:37.0 +0900
@@ -47,6 +47,7 @@ static void print_usage(void)
{
printf(usage: btrfsctl [ -d file|dir] [ -s snap_name subvol|tree ]\n);
printf([-r size] [-A device] [-a] [-c] [-D dir .]\n);
+ printf([-l dir]\n);
printf(\t-d filename: defragments one file\n);
printf(\t-d directory: defragments the entire Btree\n);
printf(\t-s snap_name dir: creates a new snapshot of dir\n);
@@ -56,6 +57,7 @@ static void print_usage(void)
printf(\t-a: scans all devices for Btrfs filesystems\n);
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(%s\n, BTRFS_BUILD_VERSION);
exit(1);
}
@@ -88,6 +90,169 @@ static int open_file_or_dir(const char *
}
return fd;
}
+
+static noinline int btrfs_gather_under_one_subvolume(int fd,
+ unsigned long command,
+ struct btrfs_ioctl_subvol_args *svargs,
+ u64 tree_id,
+ struct list_head *list,
+ int len)
+{
+ u64 last_tree = 0ULL;
+ int i, ret = 1, local_size;
+
+ while (ret 0) {
+
+ svargs-leaf = malloc(len);
+ if (!svargs-leaf)
+ return -1;
+ svargs-len = len;
+ svargs-leaf-len = len;
+ svargs-leaf-nritems = 0;
+ svargs-leaf-last_tree = last_tree;
+ svargs-leaf-parent_tree = tree_id;
+
+again:
+ ret = ioctl(fd, command, svargs);
+ if (ret 0) {
+ free(svargs-leaf);
+ svargs-leaf = NULL;
+ return -1;
+ }
+ if (svargs-leaf-nritems == 0) {
+ free(svargs-leaf);
+ if (ret 0) {
+ local_size = (svargs-next_len + 1) * 2 +
+ offsetof(struct
btrfs_ioctl_subvol_leaf, items) +
+ sizeof(struct
btrfs_ioctl_subvol_items)*2;
+ svargs-leaf = malloc(local_size);
+ if (!svargs-leaf)
+ return -1;
+ svargs-len = local_size;
+ svargs-leaf-len = local_size;
+ svargs-leaf-last_tree = last_tree;
+ svargs-leaf-parent_tree = tree_id;
+ goto again;
+ }
+ } else {
+ for (i = 0; i svargs-leaf-nritems; i++)
+
INIT_LIST_HEAD(svargs-leaf-items[i].children);
+ list_add_tail(svargs-leaf-brother, list);
+ last_tree = svargs-leaf-last_tree;
+ }
+ }
+ return 0;
+}
+
+int btrfs_gather_subvolumes(int fd, unsigned long command,
+ struct btrfs_ioctl_subvol_args *svargs,
+ u64 tree_id, struct list_head *list_top, int len)
+{
+ struct btrfs_ioctl_subvol_leaf *cur;
+ int i;
+
+ if (btrfs_gather_under_one_subvolume(fd, command, svargs, tree_id,
+ list_top, len))
+ return -1;
+ list_for_each_entry(cur, list_top, brother) {
+ for(i = 0; i cur-nritems; i++) {
+ if (btrfs_gather_subvolumes( fd, command, svargs,
+ cur-items[i].tree_id, cur-items[i].children,
len))
+ return -1;
+ }
+ }
+ return 0;
+}
+
+int btrfs_free_subvolume_info(struct list_head *list_top)
+{
+ struct btrfs_ioctl_subvol_leaf *cur, *tmp;
+ int i;
+
+ list_for_each_entry_safe(cur, tmp, list_top, brother) {
+ for(i = 0; i cur-nritems; i++) {
+ if (!list_empty(cur-items[i].children))
+
btrfs_free_subvolume_info(cur-items[i].children);
+ }
+ list_del(cur-brother);
+ free(cur);
+ }
+ return 0;
+}
+
+int btrfs_show_subvolume(struct list_head *list_top, char *path,
+ int *seq)
+{
+ int nr = *seq, i;
+ int base_path_len, path_len;
+ struct
[PATCH] Snapshot/subvolume listing feature
I made Snapshot/subvolume listing feature. This feature consists of two patches, for kernel(ioctl), and for progs(btrfsctl). I send these two patches as response of this mail soon. New option '-l' is introduced to btrfsctl for listing. If this option is specified, btrfsctl call new ioctl. New ioctl searches root tree and enumerates subtrees. For each subtrees, ioctl searches directory path to tree root, and enumerates more descendant until no more subtree is found. MANPAGE-like option description and examples are as follows. OPTIONS -l _file_ List all snapshot/subvolume directories under a tree which _file_ belongs to. EXAMPLES # btrfsctl -l /work/btrfs Base path = /work/btrfs/ No.Tree ID Subvolume Relative Path 1 256 ss1/ 2 257 ss2/ 3 258 svs1/ss1/ 4 259 svs1/ss2/ 5 260 svs2/ss1/ 6 261 svs2/ss2/ 7 262 ss3/ 8 263 ss4/ 9 264 sv_pool/ 10 265 sv_pool/ss01/ 11 266 sv_pool/ss02/ 12 267 sv_pool/ss03/ 13 268 sv_pool/ss04/ 14 269 sv_pool/ss05/ 15 270 sv_pool/ss06/ 16 271 sv_pool/ss07/ 17 272 sv_pool/ss08/ 18 273 sv_pool/ss09/ 19 274 sv_pool/ss10/ operation complete Btrfs v0.19-9-gd67dad2 Regards, 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
Re: [PATCH] Snapshot/subvolume listing feature
I'm sorry, I forgot Signed-off line. Please add this line. Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com -- 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] Deny sys_link across subvolumes.
Chris Mason wrote: On Thu, Nov 12, 2009 at 04:14:26PM +0900, TARUISI Hiroaki wrote: From: Christian Parpart tra...@gentoo.org I rebased Christian Parpart's patch to deny hard link across subvolumes. Original patch modifies also btrfs_rename, but I excluded it because we can move across subvolumes now and it make no problem. Thanks for sending this in again. Actually, we still can't rename across subvolumes, but we do support renaming subvolumes. Do you have some time to add more checks to rename as well? -chris -- 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 Thank you for your reply. I tried moving file/directory/subvolume across subvolumes, and found it worked. In source code of btrfs_rename, it's already checked if 'from' directory and 'to' directory are under a same root or not except a root object. If not matched, btrfs_rename returns with -EXDEV but it seems mv command treats it properly. Even if in no-check case (root object case), I tried but found no serious problem. I wonder renaming subvolumes across subvolumes does not completely work yet in some points I cannot found, or btrfs_rename works without returning -EXDEV. Could you tell me how should we check when renaming subvolumes? Regards, 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
[PATCH] Deny sys_link across subvolumes.
From: Christian Parpart tra...@gentoo.org I rebased Christian Parpart's patch to deny hard link across subvolumes. Original patch modifies also btrfs_rename, but I excluded it because we can move across subvolumes now and it make no problem. - Hard link across subvolumes should not allowed in Btrfs. btrfs_link checks root of 'to' directory is same as root of 'from' file. If not same, btrfs_link returns -EPERM. Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com --- fs/btrfs/inode.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 78139ef..c7f66e4 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4284,6 +4284,10 @@ static int btrfs_link(struct dentry *old_dentry, struct inode *dir, if (inode-i_nlink == 0) return -ENOENT; + /* do not allow sys_link's with other subvols of the same device */ + if (root-objectid != BTRFS_I(inode)-root-objectid) + return -EPERM; + /* * 1 item for inode ref * 2 items for dir items -- 1.6.5 -- 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
Re: Way to quickly revert back to a snapshot?
I'm trying to make this snapshots/subvolumes listing feature, I wonder how the interface should be. I tried to make this feature using ioctl interface, but I don't know how to notify all subvolume informations because number of subvolumes are not known before search. (It may work, that we call number-notify ioctl before subvol- listing ioctl itself, or we call subvol-listing ioctl repeatedly to last subvolume. But both seem to be not good to me.) Is there any other idea? Chris Mason wrote: On Sat, Oct 17, 2009 at 01:20:28PM -0400, John Dong wrote: Suppose I want to do test something insane (like a massive OS update) to my system, and create a snapshot before doing so. Afterwards, if I decide my system is hosed and I'd like to revert back to the snapshot and forget any of this actually happened, what's the quickest way of doing it. It seems like by btrfs's design there should be a way to just set the head of the filesystem back to the snapshot, like git-reset, right? This is near the top of the list of features I want to add for 2.6.33. Basically all we need is a way to swap the default subvolume (which is just a directory entry) pointer with another subvolume. We also want a way to find an snapshot all the subvolumes and snapshots underneath a given root. That way the user won't have to do it manually (snapshotting isn't recursive by default). If anyone is interested in a coding project, both are fairly easy, just let me know. -chris -- 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
Hard link across subvolumes
Hi, In Btrfs, a hard link across subvolumes should be prohibited, but not prohibited yet. (It may be convenient if possible, I think.) If we make a hard link like this, filesystem may abort or after umount/mount, contents of file may be swapped to contents of other file(with same i-node number in same tree as 'from' file). About this, I found Christian Parpart's patch posted last year, and this patch seems to work well. http://www.spinics.net/lists/linux-btrfs/msg00749.html But this patch is not merged yet. Some work(to check more, to change error code or to simply test) shuould be done for this? -- 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
[PATCH] btrfs-progs: bug fixes
Hi, I have tested btrfsck in some error case, such as item missing case or CRC error case or so. In this test session I found some bugs in btrfsck.c and disk-io.c in btrfs-progs. 1. The last pair of ptrs and items are not checked at 2 place of check_node/leaf. 2. Csum printed CRC error message is not correct. 3. In CRC error, btrfsck fails in segmentation fault. I'll post three tiny patches to fix these bugs. -- 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
[PATCH] btrfs-progs: CRC on disk printed correctly in CRC error message
I've tested btrfsck in CRC error case. However CRC on disk printed
in error message is not correct (extent_buffer itsself is printed).
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index addebe1..190301f 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -86,7 +86,7 @@ int csum_tree_block_size(struct extent_buffer *buf, u16
csum_size,
if (memcmp_extent_buffer(buf, result, 0, csum_size)) {
printk(checksum verify failed on %llu wanted %X
found %X\n, (unsigned long long)buf-start,
- *((int *)result), *((int *)buf));
+ *((int *)result), *((int *)buf-data));
free(result);
return 1;
}
--
1.6.2.1
--
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] btrfsck.c typo?
Hi,
Recently, I've red btrfsck.c of btrfs-progs to study the internal of btrfs.
However, I may find typo in pick_next_pending() of btrfsck.c
The first index of bits[] which is initialized should be 0, I think.
Signed-off-by: TARUISI Hiroaki taruishi.hir...@jp.fujitsu.com
---
diff --git a/btrfsck.c b/btrfsck.c
index 40c90f8..f961c9b 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -1920,7 +1920,7 @@ static int pick_next_pending(struct cache_tree *pending,
cache = find_first_cache_extent(reada, 0);
if (cache) {
bits[0].start = cache-start;
- bits[1].size = cache-size;
+ bits[0].size = cache-size;
*reada_bits = 1;
return 1;
}
--
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
Redundant check in verify_parent_transid
Hi,
In verify_parent_transid() of disk-io.c (btrfs-progs), I found
redundant check.
---
static int verify_parent_transid(struct extent_io_tree *io_tree,
struct extent_buffer *eb, u64 parent_transid)
{
int ret;
if (!parent_transid || btrfs_header_generation(eb) == parent_transid)
~
---
If second check is true in this sentense, then the function return.
So the next if sentence is not estimated.
---
return 0;
if (extent_buffer_uptodate(eb)
btrfs_header_generation(eb) == parent_transid) {
~
ret = 0;
goto out;
}
---
However, here has same check which looks redundant.
I guess here includes a bug, but I'm not sure.
Could someone tell me why?
---
printk(parent transid verify failed on %llu wanted %llu found %llu\n,
(unsigned long long)eb-start,
(unsigned long long)parent_transid,
(unsigned long long)btrfs_header_generation(eb));
ret = 1;
---(snip)---
--
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
