Re: subvolume/snapshot usage question
Hello tsuraan, bcp is what you need. bcp is part of btrfs-prog-unstable See http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02292.html BR Goffredo On Saturday 22 August 2009, tsuraan wrote: Suppose I have a directory under my home on a btrfs filesystem where I store virtual machine images. I have one base virtual machine, and from it I make copies that I actually run. To make a copy of a VM today, I do cp -r, which seems pretty wasteful since the VMs are almost entirely identical. Is there some way that I can do a snapshot of just the directory that holds my base VM, and then mount different forks of that snapshot to be the bases of my different running machines? It looks like I could create a snapshot of the root of my btrfs filesystem for each vm, mount that snapshot somewhere, and run the vm from that full fs snapshot, but that's not ideal. I could also create a large file for my base VM directory, format it btrfs, mount it using the loopback device, and then mount snapshots of that loopback filesystem, but having to preallocate filesystem space for my VMs is not as nice as being able to share space with the rest of my filesystem. Is there a partial-snapshot capability in btrfs? I don't understand what subvolumes are, and I think they're unrelated to what I want, but the name sounds promising... -- 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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Btrfs programs repository a bit old ?
Hi, I noticed that the official repository[*] for the btrfs program is quite old. The last commit is dated June 2009. btrfs-progs-unstable$ git log | head -3 commit 4f89b6eb0718ade63152791db32794da78fbba70 Author: Yan Zheng zheng@oracle.com Date: Fri Jun 12 12:55:50 2009 -0400 I am interested to test the Yan's patches about the snapshot removing, but I need the btrfs utils updated ! Is there another updated repository for the btrfs programs or I have to apply the Yan's patches by hands :-) BR G.Baroncelli [*] git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs- unstable.git -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Mass-Hardlinking Oops
On Monday 12 October 2009, jim owens wrote: Pär Andersson wrote: I just ran into the max hard link per directory limit, and remembered this thread. I get EMLINK when trying to create more than 311 (not 272) links in a directory, so at least the BUG() is fixed. What is the reason for the limit, and is there any chance of increasing it to something more reasonable as Mikhail suggested? For comparison I tried to create 200k hardlinks to the the same file in the same directory on btrfs, ext4, reiserfs and xfs: what real-world application uses and needs this many hard links? jim For me 311 hard link to the same file under the same directory limit is not so high. I don't know a software which need so many hard links. But it easy to find some similar cases. For example under my /usr/bin I have 478 _soft links_ to _different_ files. $ find /usr/bin/ -type l | wc -l 478 When a directory is created, its .. entry is a hard link to the parent directory. For example the /usr/share/doc directory has 2828 hard links because it has 2826 children directories. $ ls -ld /usr/share/doc drwxr-xr-x 2828 root root 12288 2009-08-20 19:03 /usr/share/doc $ ls -ld /usr/share/* | egrep ^d | wc -l 2826 These cases are different cases. But the 311 hard link to the same file under the same directory limit may be too strong. Not now but in the next format change I think that it would be useful to remove this limit. BR Goffredo -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Btrfs snapshots feature proposal for Fedora 13
On Tuesday 17 November 2009, Chris Ball wrote:
Hi,
I've written up a draft of an Fedora 13 feature proposal for
filesystem rollback using Btrfs snapshots that are automatically
created by yum:
https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs
It'd be great to get feedback on whether this is a good idea, and how
the UI interaction should work. We're also discussing it in this
fedora-devel thread:
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/123695
Some comments I've got already received, from the thread:
* People want the UI to allow independent active snapshots per
filesystem (i.e. btrfs /home is the live filesystem, and btrfs / is
an older snapshot).
On the basis of some empirical tests, I discovered that in btrfs a snapshot
doesn't doens't affect the other subvolume(s). If / (root) and /home are
different subvolumes, a snapshot of the / (root) doesn't affect the /home
content, and viceversa.
So if the root and the /home directory (or better the userS directories) are
separate volumes, you have the required behavior.
* Several people think that the ZFS Time Slider patches to nautilus¹
look good, and want that for btrfs. Sounds plausible, but I'm
more interested in first working on ways to let developers feel
comfortable upgrading to the development version of Fedora each
day with the possibility of reverting.
* Instead of inventing a new system-config-blah, this should probably
be part of Palimpsest².
* Perhaps we should encourage people using the Fedora installer with
btrfs to create a rootfs separate to their /home, so that they can
rollback rootfs snapshots without affecting their homedir.
On the basis of my tests, I think that is sufficient to create a volume for
the root ('/') and on for the /home (or a specific subvolume for every user).
Then it is possible to snapshot and time sliding every subvolume without
affecting the others.
I would like to add a my comment: in btrfs I think that snapshot (for the
btrfs snapshot) is not the best name. I think that a better term is branch.
For example the btrfs snapshot capability may be used not only for recovering
from a mistake, but also may be used for maintaining different
configurations...
Thanks!
- Chris.
BR
G.Baroncelli
¹: http://blogs.sun.com/erwann/entry/zfs_on_the_desktop_zfs
http://blogs.sun.com/erwann/entry/time_slider_screencast
http://blogs.sun.com/erwann/entry/new_time_slider_features_in
²: http://library.gnome.org/users/palimpsest/stable/intro.html.en
--
Chris Ball c...@laptop.org
One Laptop Per Child
--
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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Re: [RFC] proposal for a btrfs filesystem layout
Hi Chris,
On Friday 20 November 2009, Chris Mason wrote:
On Fri, Nov 20, 2009 at 07:50:06PM +0100, Goffredo Baroncelli wrote:
Hi all,
after the Chirs (Ball) email, I thought about a possible btrfs file-system
layout, which may permit to snapshot the root and mount (if required) an
old
snapshot of the root.
[ very clear description of a filesystem tree layout ]
Any comments ?
This is definitely possible, but not strictly required. We'll be able
to create an ioctl (or mount option) that replaces the default subvolume
('.' in your examples) pointer with a pointer to another subvolume, and
an ioctl to delete the old root.
That was my first thought... but so the risk is to implement with ioctl(s)
commands (rename, delete, list ) that
a) already exist in the VFS abstraction.
b) refer to objects that are like directories (in fact the differences
between a volume and a directory are very small)
Basically it will end up hiding the extra layer of indirection your
proposal adds.
Yes, my idea introduces an extra layer, that
a) is different from all other file-systems
b) is not useful if you don't use the snapshot at all
And both a) and b) are not good point :((
This doesn't mean your ideas were bad, my plan all along
has been to leave this up to the distros to work out with the users, and
give them enough tools that they have the flexibility to do what they
need.
My concern is about the btrfs user interface.
The biggest difficult that I had to learn the btrfs capabilities is its user-
interface. I have to admit to be not the smartest person, but I spent a lot
of time in order to understand which was the difference between a btrfs
subvolume creation and a mkfs + mount.
Finally I concluded that there no is difference (except the COW behaviour and
other implementation detail). My impression was that in some area too often
the VFS and btrfs do the same things. [*]
The point is that if btrfs do the same things of VFS, this may be called as
flexibility.
But the history has highlight that from a long term point of view is the
orthogonality of the subsystems that leads to the flexibility of the system..
I definitively need to sleep. Now in Italy is deep night and it is too late to
email about orthogonality of the subsystems..
In any case, thank you Chris for your work for btrfs. And read my comment only
as suggestion to improve btrfs.
-chris
Goffredo
[*] May be that my confusion is due to the fact that when btrfs creates a
subvolume, two different actions were performed
- a new subvolume is create (and definitely this is a btrfs competence)
- the new subvolume is mounted in a new directory (and I think that this is a
VFS competence).
That raise me a question: what about to separate the subvolume creation from
the subvolume mounting ? That definitely put the two kind of objects
(directories and subvolume) in two different name-spaces: Btrfs will be
responsible to create subvolume (and handle the COW/snapshot semantic), and
the mounting will be responsible to the VFS.
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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] proposal for a btrfs filesystem layout
Chris Mason wrote: On Sat, Nov 21, 2009 at 12:31:06AM +0100, Goffredo Baroncelli wrote: [...] My concern is about the btrfs user interface. The biggest difficult that I had to learn the btrfs capabilities is its user- interface. I have to admit to be not the smartest person, but I spent a lot of time in order to understand which was the difference between a btrfs subvolume creation and a mkfs + mount. Finally I concluded that there no is difference (except the COW behaviour and other implementation detail). My impression was that in some area too often the VFS and btrfs do the same things. [*] The point is that if btrfs do the same things of VFS, this may be called as flexibility. But the history has highlight that from a long term point of view is the orthogonality of the subsystems that leads to the flexibility of the system.. Well, btrfs is using the VFS to expose the subvolumes. Basically a subvolume is a special directory. Let me explain better: what I would say was to expose the sub-volume content *only* with a command like mount -o subvol=name. To day when I create a snapshot, automatically it is placed in the btrfs filesystem with the snapshot name. IIRC when I move (rename) the directory I change the subvolume/snapshot name also. Yes, I can remount the sub-volume with the mount command anywhere and with an arbitrary name. In fact the thing that seems strange to me is that when I create a snapshot, immediately it is mounted: it is not a real problem, it is only a strange behaviour. The standard behaviour is to create the file-system and then mount it: two separate actions. -chris Goffredo -- 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 Josef On Friday 04 December 2009, 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. Nice feature. But only for clarification purpose I have to correct you: the only limit of the subvol= mount option is that the volume name or snapshot name have to be under the root of the btrfs filesystem (or if you prefer under the root of the . volume). So: - a subvolume created under / may be mounted using the subvol= mount option - a subvolume created under a directory *can't* be mounted using the subvol= mount option - a subvolume created under a directory and moved under / *may* be mounted using the subvol= mount option - a snapshot of a subvolume created under / may be mounted using the subvol= option And so... (As side note: a subvol may be renamed/moved with a simple mv command.) In fact the subvol= mount option related code, search in the root of the btrfs a subvolume/snapshot named as required, then mount it. Doesn't matter if it is a snapshot of a subvolume or where it is originally created. In any case I like your idea. BR G.Baroncelli -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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 mysteries (and an oops)
On Saturday 12 December 2009, Andy Lutomirski wrote: Goffredo Baroncelli wrote: [...] Yes the docs may be improved. The syntax is: btrfsctl -D snapshotname directory snapshotname snapshot name directory where the snapshot is What's the point of the last parameter? Can't either btrfsctl or the filesystem figure that out on its own? Pay attention that you can have different sub-volumes with the same name in different directories. It would be better if the directory is extracted from the name.. (Can a subvolume be mounted in two places at once? If so, maybe the second parameter makes a tiny bit of sense.) Yes, a subvolume may be mounted in two places (mount -t btrfs -o subvol=subvolumename ...); but that doesn't matter: if you remove a subvolume.. you remove iteverywhere. --Andy Goffredo -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
On Saturday 12 December 2009, 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. I try an explanation below 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. I can add further details. The next boot my machine was un-bootable. The reasons was that the *soft link* /lib64 (which pointed to /lib) was wrong. My explanation of the fact is: - In my root there was the link /lib64 - lib; the file /lib64 had inode number = 257. - I created a subvolume for my test. Under this subvolume I created a file (called myfile) which (casually) had inode number = 257. - I hard linked the file myfile (which inode number 257) in my root volume. - Unfortunately the inode number of the linked file, existed already and was the one of the /lib64 link. - When I removed the subvolume used for my test, the two file (/lib64 and the linked target) exchanged its content and the hard-link becames a soft link and vice-versa. The final results was: - an unbootable machine - three files with the same inode (and with a ref count equal to two !!) On the basis of the facts above, I suggest to Chris to raise the importance of the patch of TARUISI Hiroaki (see email [PATCH] Deny sys_link across subvolumes 12/11/2009). BR Goffredo -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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][TRIVIAL] Improve the btrfsctl help
On Sunday 13 December 2009, sniper wrote:
2009/12/12 Goffredo Baroncelli kreij...@gmail.com:
Hi all,
[...]
+ printf(\t-D name dir: delete a snapshot or subvolume of dir\n);
Hi, should it be delete a snapshot or subvolume _in_ dir?
Right,
Patch updated
BR
Goffredo
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
---
btrfsctl.c | 33 +++--
1 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/btrfsctl.c b/btrfsctl.c
index 66c4e89..6f6e8e6 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -45,17 +45,18 @@ static inline int ioctl(int fd, int define, void *arg) {
return 0; }
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(usage: btrfsctl [-d file|dir] [-s snap_name subvol]\n);
+ printf([-S vol_name dir] [-a] [-r size subvol]\n);
+ printf([-A device] [-c subvol] [-D name subvol]\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);
- printf(\t-S subvol_name dir: creates a new subvolume\n);
- printf(\t-r [+-]size[gkm]: resize the FS by size amount\n);
- printf(\t-A device: scans the device file for a Btrfs filesystem\n);
+ printf(\t-s snap_name subvol: creates a new snapshot of subvol\n);
+ printf(\t-S subvol_name dir: creates a new subvolume in dir\n);
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-r [+-]size[gkm] subvol: resize the FS by size amount\n);
+ printf(\t-A device: scans the device file for a Btrfs filesystem\n);
+ printf(\t-c subvol: forces a single FS sync\n);
+ printf(\t-D name dir: delete a snapshot or subvolume in dir\n);
printf(%s\n, BTRFS_BUILD_VERSION);
exit(1);
}
@@ -110,7 +111,7 @@ int main(int ac, char **av)
for (i = 1; i ac; i++) {
if (strcmp(av[i], -s) == 0) {
if (i + 1 = ac - 1) {
- fprintf(stderr, -s requires an arg);
+ fprintf(stderr, -s requires two args\n);
print_usage();
}
fullpath = av[i + 1];
@@ -137,7 +138,7 @@ int main(int ac, char **av)
command = BTRFS_IOC_SNAP_CREATE;
} else if (strcmp(av[i], -S) == 0) {
if (i + 1 = ac - 1) {
- fprintf(stderr, -S requires an arg);
+ fprintf(stderr, -S requires two args\n);
print_usage();
}
name = av[i + 1];
@@ -160,8 +161,8 @@ int main(int ac, char **av)
}
command = BTRFS_IOC_DEFRAG;
} else if (strcmp(av[i], -D) == 0) {
- if (i = ac - 1) {
- fprintf(stderr, -D requires an arg\n);
+ if (i + 1 = ac - 1) {
+ fprintf(stderr, -D requires two args\n);
print_usage();
}
command = BTRFS_IOC_SNAP_DESTROY;
@@ -178,8 +179,8 @@ int main(int ac, char **av)
}
command = BTRFS_IOC_SCAN_DEV;
} else if (strcmp(av[i], -r) == 0) {
- if (i = ac - 1) {
- fprintf(stderr, -r requires an arg\n);
+ if (i+1 = ac - 1) {
+ fprintf(stderr, -r requires two args\n);
print_usage();
}
name = av[i + 1];
@@ -190,6 +191,10 @@ int main(int ac, char **av)
}
command = BTRFS_IOC_RESIZE;
} else if (strcmp(av[i], -c) == 0) {
+ if (i = ac - 1) {
+ fprintf(stderr, -c requires an arg\n);
+ print_usage();
+ }
command = BTRFS_IOC_SYNC;
}
}
signature.asc
Description: This is a digitally signed message part.
[PATCH] Improve the btrfsctl help
) {
+ fprintf(stderr, -r requires two args\n);
print_usage();
}
name = av[i + 1];
len = strlen(name);
if (len == 0 || len = BTRFS_VOL_NAME_MAX) {
- fprintf(stderr, -r size too long\n);
+ fprintf(stderr,
+-r argument zero length or too long\n);
exit(1);
}
command = BTRFS_IOC_RESIZE;
} else if (strcmp(av[i], -c) == 0) {
+ if (i = ac - 1) {
+ fprintf(stderr, -c requires an arg\n);
+ print_usage();
+ }
command = BTRFS_IOC_SYNC;
}
}
diff --git a/man/btrfsctl.8.in b/man/btrfsctl.8.in
index c2d4488..b645429 100644
--- a/man/btrfsctl.8.in
+++ b/man/btrfsctl.8.in
@@ -4,12 +4,13 @@ btrfsctl \- control a btrfs filesystem
.SH SYNOPSIS
.B btrfsctl
[ \fB\-d\fP\fI file|directory \fP ]
-[ \fB\-s\fP\fI snapshot-name directory\fP ]
+[ \fB\-s\fP\fI snapshot-name subvolume\fP ]
[ \fB \-S\fP\fI subvolume-name directory\fP ]
-[ \fB \-r\fP\fI [+-]size\fP ]
+[ \fB \-r\fP\fI [devid:][+-]size[kmg]\fP tree]
[ \fB \-A\fP\fI device\fP ]
[ \fB \-a\fP ]
-[ \fB \-c\fP ]
+[ \fB \-c\fP tree]
+[ \fB \-D\fP\fI subvolume-name directory\fP ]
.SH DESCRIPTION
.B btrfsctl
is used to control the filesystem and the files and directories stored. It is
the tool to
create a new snapshot for the filesystem.
@@ -18,14 +19,21 @@ is used to control the filesystem and the files and
directories stored.
It is th
\fB\-d\fR \fIfile|directory\fR
Defragment a file or a directory. If the argument is a directory, the entire
b-tree under
the directory is defragged.
.TP
-\fB\-s\fR \fIsnapshot-name directory\fR
-Creates a new \fIsnapshot\fP of the \fIdirectory\fP specified.
+\fB\-s\fR \fIsnapshot-name subvolume\fR
+Creates a new \fIsnapshot\fP of the \fIsubvolume\fP specified. In the
+\fIsnapshot-name\fP may be specify the path where the snapshot will be placed.
+\fIsubvolume\fP may be specified with any file or directory of the subvolume.
.TP
\fB\-S\fR \fIsubvolume-name directory\fR
-Creates a new subvolume.
+Creates a new \fIsubvolume\fP in the \fIdirectory\fP specified.
.TP
-\fB\-r\fR \fI[+|-]size\fR
-Resizes the filesystem with the \fIsize\fP specified. If the value is preceded
with a
signed symbol, the filesystem is resized with respect to the current filesystem
size.
\fIsize\fP can be suffixed by k,m or g to represent kilobytes, megabytes, or
gigabytes
respectively.
+\fB\-r\fR \fI[devid:][+|-]size[kmg] tree\fR
+Resizes the filesystem with the \fIsize\fP specified. If the value is preceded
+with a signed symbol, the filesystem is resized with respect to the current
+filesystem size. \fIsize\fP can be suffixed by k,m or g to represent kilobytes,
+megabytes, or gigabytes respectively. For a multi-device filesystem the
+\fIdevid\fP parameter specify which device has to be resize (default 1).
+\fItree\fP may be any element of the filesystem involved.
.TP
\fB\-A\fR \fIdevice\fR
Scans the \fIdevice\fR for btrfs filesystem.
@@ -33,8 +41,12 @@ Scans the \fIdevice\fR for btrfs filesystem.
\fB\-a\fR
Scans all devices present in the system for btrfs filesystem.
.TP
-\fB\-c\fR
-Forces a filesystem sync.
+\fB\-c\fR \fItree\fR
+Forces a filesystem sync. \fItree\fP may be any element of the filesystem
+involved.
+.TP
+\fB\-D\fR \fIsubvolume-name directory\fR
+Delete a subvolume in the directory specified.
.SH AVAILABILITY
.B btrfsctl
is part of btrfs-progs. Btrfs is currently under heavy development,
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Re: btrfs-progs: New utility to swap subvolumes
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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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 2/2] [Repost] btrfslabel - kernel space
This is the second patch, the one kernel related. This patch introduces two new
ioctls to read and change the label of a btrfs filesystem.
This patch is a repost of a previous patch of Morey Roof.
If request I can modify the patch. Comments are welcome.
BR
G.Baroncelli
---
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 645a179..18f3ada 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1301,6 +1301,53 @@ long btrfs_ioctl_trans_end(struct file *file)
return 0;
}
+long btrfs_ioctl_set_label(struct btrfs_root *root, void __user *arg)
+{
+ struct btrfs_trans_handle *trans;
+ struct btrfs_ioctl_label_args *label_args;
+ int ret = 0;
+
+ label_args = kmalloc(sizeof(*label_args), GFP_NOFS);
+
+ if (!label_args)
+ return -ENOMEM;
+
+ if (copy_from_user(label_args, arg, sizeof(*label_args)))
+ {
+ ret = -EFAULT;
+ } else
+ {
+ /* Everything looks good, so lets do a label change */
+ label_args-name[BTRFS_LABEL_SIZE] = 0x00;
+ trans = btrfs_start_transaction(root, 1);
+ strncpy(root-fs_info-super_copy.label, label_args-name,
BTRFS_LABEL_SIZE);
+ btrfs_commit_transaction(trans, root);
+ }
+
+ kfree(label_args);
+ return ret;
+}
+
+long btrfs_ioctl_get_label(struct btrfs_root *root, void __user *arg)
+{
+ struct btrfs_ioctl_label_args *label_args;
+ int ret = 0;
+
+ label_args = kmalloc(sizeof(*label_args), GFP_NOFS);
+
+ if (!label_args)
+ return -ENOMEM;
+
+ strncpy(label_args-name, root-fs_info-super_copy.label,
BTRFS_LABEL_SIZE);
+ if (copy_to_user(arg, label_args, sizeof(*label_args)))
+ {
+ ret = -EFAULT;
+ }
+
+ kfree(label_args);
+ return ret;
+}
+
long btrfs_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
{
@@ -1338,6 +1385,10 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_trans_start(file);
case BTRFS_IOC_TRANS_END:
return btrfs_ioctl_trans_end(file);
+ case BTRFS_IOC_SET_LABEL:
+ return btrfs_ioctl_set_label(root, (void __user *)arg);
+ case BTRFS_IOC_GET_LABEL:
+ return btrfs_ioctl_get_label(root, (void __user *)arg);
case BTRFS_IOC_SYNC:
btrfs_sync_fs(file-f_dentry-d_sb, 1);
return 0;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index bc49914..995756d 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -19,6 +19,7 @@
#ifndef __IOCTL_
#define __IOCTL_
#include linux/ioctl.h
+#include ctree.h
#define BTRFS_IOCTL_MAGIC 0x94
#define BTRFS_VOL_NAME_MAX 255
@@ -30,6 +31,10 @@ struct btrfs_ioctl_vol_args {
char name[BTRFS_PATH_NAME_MAX + 1];
};
+struct btrfs_ioctl_label_args {
+ char name[BTRFS_LABEL_SIZE + 1];
+};
+
struct btrfs_ioctl_clone_range_args {
__s64 src_fd;
__u64 src_offset, src_length;
@@ -67,4 +72,11 @@ struct btrfs_ioctl_clone_range_args {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_SNAP_DESTROY _IOW(BTRFS_IOCTL_MAGIC, 15, \
struct btrfs_ioctl_vol_args)
+
+/* Used to set and get the current volume label */
+#define BTRFS_IOC_SET_LABEL_IOW(BTRFS_IOCTL_MAGIC, 16, \
+ struct btrfs_ioctl_label_args)
+#define BTRFS_IOC_GET_LABEL_IOW(BTRFS_IOCTL_MAGIC, 17, \
+ struct btrfs_ioctl_label_args)
+
#endif
---
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
[PATCH 1/2] [Repost] btrfslabel - user space
, \
struct btrfs_ioctl_vol_args)
+
+/* Used to set and get the current volume label */
+#define BTRFS_IOC_SET_LABEL_IOW(BTRFS_IOCTL_MAGIC, 16, \
+ struct btrfs_ioctl_label_args)
+#define BTRFS_IOC_GET_LABEL_IOW(BTRFS_IOCTL_MAGIC, 17, \
+ struct btrfs_ioctl_label_args)
+
#endif
diff --git a/utils.c b/utils.c
index 2f4c6e1..51cff4a 100644
--- a/utils.c
+++ b/utils.c
@@ -587,7 +587,7 @@ error:
}
/*
- * returns 1 if the device was mounted, 0 on error or 0 if everything
+ * returns 1 if the device is mounted, 0 on error or 0 if everything
* is safe to continue. TODO, this should also scan multi-device filesystems
*/
int check_mounted(char *file)
@@ -638,6 +638,39 @@ int check_mounted(char *file)
return ret;
}
+/* Gets the mount point of btrfs filesystem that is using the specified device.
+ * Returns 0 is everything is good, 0 if we have an error.
+ * TODO: Fix this fucntion and check_mounted to work with multiple drive BTRFS
+ * setups.
+ */
+int get_mountpt(char *dev, char *mntpt, size_t size)
+{
+ struct mntent *mnt;
+ FILE *f;
+ int ret = 0;
+
+ f = setmntent(/proc/mounts, r);
+ if (f == NULL)
+ return -errno;
+
+ while ((mnt = getmntent(f)) != NULL )
+ {
+ if (strcmp(dev, mnt-mnt_fsname) == 0)
+ {
+ strncpy(mntpt, mnt-mnt_dir, size);
+ break;
+ }
+ }
+
+ if (mnt == NULL)
+ {
+ /* We didn't find an entry so lets report an error */
+ ret = -1;
+ }
+
+ return ret;
+}
+
struct pending_dir {
struct list_head list;
char name[256];
@@ -820,3 +853,27 @@ char *pretty_sizes(u64 size)
return pretty;
}
+/*
+ * Checks to make sure that the label matches our requirements.
+ * Returns:
+ 0if everything is safe and usable
+ -1if the label is too long
+ -2if the label contains an invalid character
+ */
+int check_label(char *input)
+{
+ int i;
+ int len = strlen(input);
+
+ if (len BTRFS_LABEL_SIZE) {
+ return -1;
+ }
+
+ for (i = 0; i len; i++) {
+ if (input[i] == '/' || input[i] == '\\') {
+ return -2;
+ }
+ }
+
+ return 0;
+}
diff --git a/utils.h b/utils.h
index 7ff542b..838b65e 100644
--- a/utils.h
+++ b/utils.h
@@ -40,4 +40,6 @@ int check_mounted(char *devicename);
int btrfs_device_already_in_root(struct btrfs_root *root, int fd,
int super_offset);
char *pretty_sizes(u64 size);
+int check_label(char *input);
+int get_mountpt(char *dev, char *mntpt, size_t size);
#endif
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/2] [Repost] btrfslabel - user space
On Monday 04 January 2010, Goffredo Baroncelli wrote: Hi all, recently I needed to change a label of a btrfs filesystem. After a bit of googling I discovered the Morey patches (dated august 2008). So I update the patches to the latest btrfs source. The patches creates a new command called btrfslabel which is able to change the label of a btrfs filesystem. The command differentiates two cases: - the filesystem is mounted: the change is done by the kernel (see the second patch), btrfslabel uses an ioctl to start the label changing. - the filesystem is unmounted: the change is performed in user space. I forgot to mention that even if the kernel isn't patched, it is still possible to change a label of an unmounted btrfs filesystem. -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
On Wednesday 06 January 2010, TARUISI Hiroaki wrote: 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. I wrote a little script which handle the snapshot creation/deleting/listing and grub config file update. This script supposing the layout which I discussed - under /var/btrfs is mounter the real root btrfs filesystem - under the real root file-system there are the snapshots and the root of the system (rootfs) - in /var/btrfs/snaplist.txt there is the list of snaphsot - in /boot/grub/menu.lst there is the grub configuration In you are interested, I can send you. BR Goffredo 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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Hello, here [*] you can find my script. Please pay attention to the fact that it is only tested on my *ubuntu* box. The program has 4 main commands: $ ./snapmng.sh snapmng.sh [-n] create snapname [comment] Create a new snapshot. snapmng.sh list List the snapshots. snapmng.sh [-n] delete snapname Delete a snapshot. snapmng.sh update-grub Update grub menulist. snapmng.sh help Show help (this). If the switch '-n' is passed, then 'create' and 'delete' commands don't update the grub menu. If snapname is equal to '.' in the 'create' command, the name is generated automatically like snap-MMDD. ** list This is the simplest; this function lists the snapshot on the basis of the content of the file /var/btrfs/snaplist.txt ** update-grub This is the most triky function. This function update the grub menu on the basis of the snapshot contained in the /var/btrfs/snaplist.txt. The first entry of the grub menu is extracted. Then for every snapshots this entry is added to the end of the /boot/grub/menu.lst, replacing subvol=rootfs with subvol=snapshotname. These entries are delimited by the two following rows: ### BEGIN BTRFS SNAPSHOT ITEMS [...] ### END BTRFS SNAPSHOT ITEMS So it is possible to update the /boot/grub/menu.lst file without affecting the other entries. ** create this command creates a new snapshot and update the grub config file. If the switch -n is passed the menu.lst file will not be updated. ** delete this command deletes a snapshot and update the grub config file. If the switch -n is passed the menu.lst file will not be updated I repeat the btrfs filesystem layout. Nomenclature: -- root of system - where there are the typical directories/files like /bin, /sbin /usr /etc... -- root of the (btrfs) file-system - where there are the snapshots or subvolumes Under root of the filesystem there are the *subvolume* for the root of the system. Its name is rootfs, and contains the standard filesystem (/bin /usr /sbin /etc ... ). The snapshot of the root of the system is still under / So the filesystem layout is / \ +--rootfs system root (subvolume) |\ | +--/bin | +--/sbin | +--/etc | +--/usr | [...] +--snap-123 snapshot of the system root #123 |\ | +--/bin | +--/sbin | [...] +--snap-3456 snapshot of the system root #3456 |\ | +--/bin | +--/sbin | [...] At the boot time as root is not mounted the root of the filesystem, but the subvolume/snapshot rootfs Tipically in my ubuntu the grub entry is title Ubuntu 9.10, kernel 2.6.31-17-generic root(hd0,0) kernel /vmlinuz root=/dev/sdX ro rootflags=subvol=rootfs initrd /initrd.img-2.6.31-17-generic quiet Note the part rootflags=subvol=rootfs. Pay attention that the prefix rootflags is debian related (it should works for both debian and ubuntu). For examples for Fedora, the prefix would be rootfsflags. for administration purpose the root of the btrfs filesystem is mounted under /var/btrfs. In my /etc/fstab there are the following lines: /dev/sdX / btrfs subvol=rootfs,errors=remount-ro,noatime 0 1 /dev/sdX /var/btrfs btrfs subvol=.,errors=remount-ro,noatime 0 1 [*] http://cassiopea.homelinux.net/git/?p=snapmng/.git;a=summary BR Goffredo On Wednesday 06 January 2010, you (Piavlo) wrote: Hi Goffredo, I'm interested in your script. BTW great article - seems to be very similar to how opensolaris handles boot environments with zfs. Also I think it's better to keep the /boot as separate btrfs subvolume - in order to have only one instance of /boot/grub/menu.lst and kernels independent of all the rootfs snapshots - of course this will work only of grub2 can be told to look for /boot/grub/menu.lst under the btrfs boot subvolume - otherwise we need to store the /boot as normal directory under the root subvolume of the btrfs filesystem. I've implemented your idea , but currently the /boot is stored under ext3 with legacy-grub. Need to check it will work with boot inside btrfs with grub2. Thanks Alex Goffredo Baroncelli wrote: On Wednesday 06 January 2010, TARUISI Hiroaki wrote: 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. I wrote a little script which handle the snapshot creation/deleting/listing and grub config file update. This script supposing the layout which I discussed
Re: Still Problems with /dev/btrfs-control
Hi Michael
On Saturday 09 January 2010, Dipl.-Ing. Michael Niederle wrote:
Thanks for the quick reply!
But I still have problems with btrfsctl:
stat /dev/btrfs-control
File: `/dev/btrfs-control'
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: ch/12dInode: 659848 Links: 1 Device type: a,3e
Ok, two things:
1) btrfs-control is a *character* device and _not_ a *block device*
2) on my system it is allocated under 10,55 (major/minor).
$ stat /dev/btrfs-control
File: `/dev/btrfs-control'
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: fh/15d Inode: 2404Links: 1 Device type: a,37
Access: (0660/crw-rw) Uid: (0/ root) Gid: ( 0/ root)
Access: 2010-01-09 11:35:30.764909719 +0100
Modify: 2010-01-09 11:35:30.764909719 +0100
Change: 2010-01-09 11:35:30.764909719 +0100
gh...@venice:~$ ls -l /dev/btrfs-control
crw-rw 1 root root 10, 55 2010-01-09 11:35 /dev/btrfs-control
Looking at the source
btrfs-unstable/fs/btrfs$ grep -A 2 -B 2 btrfs-control *.c
super.c-static struct miscdevice btrfs_misc = {
super.c-.minor = MISC_DYNAMIC_MINOR,
super.c:.name = btrfs-control,
super.c-.fops = btrfs_ctl_fops
super.c-};
It seems that it is dynamically allocated. The major should be always 10,
the minor may be find with
$ cat /proc/misc | grep btrfs-control
55 btrfs-control
Or by
$ cat /sys/class/misc/btrfs-control/dev
10:55
Regards
Goffredo
Access: (0644/brw-r--r--) Uid: (0/root) Gid: (0/root)
Access: 2010-01-09 11:31:15.757979602 +0100
Modify: 2010-01-09 11:31:15.757979602 +0100
Change: 2010-01-09 11:31:15.757979602 +0100
mount -l -t btrfs
/dev/sda3 on / type btrfs (rw,relatime,noacl) [Alpha4]
btrfsctl -A /dev/sda3
failed to open /dev/btrfs-control: No such device or address
Remark: When the btrfs-filesystem is originally mounted (from the startup-
code
in the initial ramdisk), /dev/btrfs-control is not yet existant, because the
dev-directory is contained in the btrfs-filesystem.
Everything else works fine.
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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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: How to mount a subvolume?
On Saturday 09 January 2010, Dipl.-Ing. Michael Niederle wrote: First thanks alot to Kay and Goffredo! But I have another question. I read that the current tools cannot display subvolumes, but one should still be able to mount them. If I try I get an error message: mount -t btrfs -o subvol=root.2010-01-07 /dev/sda3 /save mount: /dev/sda3 is not a valid block device root.2010-01-07 is a snapshot of the /root-directory /save is an empty directory used for mounting backups taken (successfully) with the following command: btrfsctl -s root.2010-01-07 /root What am I doing wrong? Isn't it possible to mount the whole filesystem and a subvolume at the same time? It is possible. I do that on my machine. The magic part is that the subvolume/snapshot (are the same thing) has to be under the / of the filesystem. gh...@arakne:/tmp$ mkdir test gh...@arakne:/tmp$ mkdir test-snap gh...@arakne:/tmp$ sudo mount -o /dev/sdc test gh...@arakne:/tmp$ mount | grep btrfs /dev/sdc on /tmp/test type btrfs (rw) gh...@arakne:/tmp$ cd test gh...@arakne:/tmp/test$ sudo mkdir a gh...@arakne:/tmp/test$ sudo btrfsctl -s a/snap-on-subdir . operation complete Btrfs Btrfs v0.19 gh...@arakne:/tmp/test$ sudo btrfsctl -s snap-of-root . operation complete Btrfs Btrfs v0.19 gh...@arakne:/tmp/test$ cd .. gh...@arakne:/tmp$ sudo mount -o subvol=snap-on-subdir /dev/sdc test-snap/ mount: /dev/sdc is not a valid block device gh...@arakne:/tmp$ sudo mount -o subvol=snap-of-root /dev/sdc test-snap/ gh...@arakne:/tmp$ mount | grep btrfs /dev/sdc on /tmp/test type btrfs (rw) /dev/sdc on /tmp/test-snap type btrfs (rw,subvol=snap-of-root) Note: - both the root of the btrfs filesystem and its snapshot are mounted at the same time - if a subvolume/snapshot not placed in the root is mounted an error is returned (/dev/sdX is not a valid block device) Greetings, Michael Goffredo -- 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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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] Include subvolume= and metadata_ratio= in /cat/proc
Hi all,
this patch include in /proc/mount the info about which subvolume is mounted
and which metadata_ratio value is used.
$ cat /proc/mounts
rootfs / rootfs rw 0 0
[...]
/dev/sdc /tmp/t4 btrfs rw,relatime,metadata_ratio=20 0 0
/dev/sdc /mnt/btrfs btrfs rw,relatime,degraded,metadata_ratio=20,subvol=snap-
of-root 0 0
BR
G.Baroncelli
commit 3d7ea7bbd70a66c4d0f369b2879c503b722e8834
Author: ghigo gh...@kreijack.homelinux.net
Date: Thu Jan 14 20:27:41 2010 +0100
Add info about metadata_ratio and subvolume name
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 3f9b457..faeaa7f 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -461,6 +461,16 @@ static int btrfs_show_options(struct seq_file *seq,
struct vfsmount *vfs)
seq_puts(seq, ,discard);
if (!(root-fs_info-sb-s_flags MS_POSIXACL))
seq_puts(seq, ,noacl);
+ if( root-fs_info-metadata_ratio )
+ seq_printf(seq, ,metadata_ratio=%d,
+ root-fs_info-metadata_ratio);
+ spin_lock(vfs-mnt_root-d_lock);
+ if (vfs-mnt_root-d_name.len != 1 ||
+ vfs-mnt_root-d_name.name[0] != '/'){
+ seq_puts(seq, ,subvol=);
+ seq_puts(seq, vfs-mnt_root-d_name.name);
+ }
+ spin_unlock(vfs-mnt_root-d_lock);
return 0;
}
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Re: Free space left
On Saturday 16 January 2010, Michael Niederle wrote: How can I detect how much free space is left on a btrfs-volume? As I read (and learned in practice!) df reports cannot be trusted if used on btrfs-volumes. Try btrfs-show $ btrfs-show Label: bar uuid: ec2918cd-ad47-4eac-9e85-5604b02fd922 Total devices 1 FS bytes used 302.25MB devid1 size 964.81MB used 614.50MB path /dev/sdc1 Label: debian-root uuid: 6e2a647f-5da2-4bd0-a7d7-9b13d13a47cc Total devices 1 FS bytes used 23.52GB devid1 size 232.11GB used 118.03GB path /dev/sdc3 Btrfs Btrfs v0.19 BR G.Baroncelli -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
On Saturday 16 January 2010, you (Dipl.-Ing. Michael Niederle) wrote: Hi, Goffredo! Try btrfs-show Thanks for your advice! btrfs-show works but it displays a lot of error message for non-btrfs devices: btrfs-show failed to read /dev/sdg failed to read /dev/sdg1 failed to read /dev/sdg2 failed to read /dev/sdg3 failed to read /dev/sdg4 failed to read /dev/md1 failed to read /dev/fd0 failed to read /dev/fd0u1440 failed to read /dev/fd1 failed to read /dev/hda failed to read /dev/hda1 failed to read /dev/hda10 failed to read /dev/hda11 failed to read /dev/hda12 ... failed to read /dev/sr0 failed to read /dev/sr1 failed to read /dev/sr2 failed to read /dev/sr3 ... Label: Alpha4 uuid: 63b82dad-ed81-41f4-910f-7b358ceb77ba Total devices 1 FS bytes used 11.81GB devid1 size 20.01GB used 20.01GB path /dev/sda3 Btrfs v0.19-4-gab8fb4c Even if I try btrfs-show /dev/sda3 I get the same output. Greetings, Michael Yes they search in every block devices a btrfs file-system. It may be smarter/faster skipping the floppy and the cd-rom.. BR G.Baroncelli -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
On Saturday 16 January 2010, you (Svein Erik Brostigen) wrote: Goffredo Baroncelli wrote: Try btrfs-show Ok: $ mount /dev/sdc on /media/452f782b-738a-4699-abfa-588eecab07ea type btrfs (rw,nosuid,nodev,uhelper=devkit) $ df /dev/sdc 932G 6.7G 925G 1% /media/452f782b-738a-4699-abfa-588eecab07ea $ btrfs-show failed to read /dev/sdb1 failed to read /dev/sdc ^ It seems that you don't have the right to read /dev/sdc. Retry as super user. [...] Btrfs Btrfs v0.19 The drive used is a Seagate FreeAgent 1Tb USB drive under Ubuntu 9.10 $ uname -a Linux ebrostig-laptop 2.6.31-18-generic-pae #55-Ubuntu SMP Fri Jan 8 16:13:23 UTC 2010 i686 GNU/Linux Erik -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Free space left
On Saturday 16 January 2010, Mathieu Chouquet-Stringer wrote: Hello, kreij...@gmail.com (Goffredo Baroncelli) writes: Try btrfs-show [...] How do you read this then: Label: none uuid: 27fafa43-7ad0-4e8a-ada8-36f73ef8984c Total devices 2 FS bytes used 79.63GB devid2 size 111.79GB used 111.01GB path /dev/sdb devid1 size 111.79GB used 111.03GB path /dev/sda I'm pretty sure I created this fs with -d raid1 -m raid1! Speaking of which, is there a way to read a FS configuration: how can I tell this FS really uses raid1 for both data and metadata? Even tough the raid mode is set per filesystem, btrfs has (will have) the capability to set the raid level per file. So it is no simple to estimate the free space: if every file is raid1 the real free space is half of the physical free space. But if some file are in raid1 (for examples /etc) and others are in raid0 (for example the ones under /usr which may be re-downloaded) the used space and the free space are difficult to estimate. There are some efforts to fix this kind of situation (see the thread [PATCH] Btrfs-progs: add btrfsctl -i to print space info). The used column is surprising: if it's a mirror why 111.01 and 111.03? And why all the space is being used anyway: I mean what's the difference between the 79.63GB and 111.0[13]? And the output of df is confusing too: /dev/sdb 234441648 83501968 150939680 36% /space It's reporting twice the total space but I think I remember looking it up and that should be fixed in a future kernel version. -- Mathieu Chouquet-Stringer mchou...@free.fr The sun itself sees not till heaven clears. -- William Shakespeare -- -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreijackATinwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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 v2 5/5] Btrfs: Add BTRFS_IOC_SUBVOL_GETFLAGS/SETFLAGS ioctl
Hi Li,
On Thursday, 09 December, 2010, Li Zefan wrote:
This allows us to set a snapshot or a subvolume readonly or writable
on the fly.
Usage:
Set BTRFS_SUBVOL_RDONLY of btrfs_ioctl_vol_arg_v2-flags, and then
call ioctl(BTRFS_IOCTL_SUBVOL_SETFLAGS);
Changelog for v2:
- Add _GETFLAGS ioctl.
- Check if the passed fd is the root of a subvolume.
- Change the name from _SNAP_SETFLAGS to _SUBVOL_SETFLAGS.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/ioctl.c | 92
++
fs/btrfs/ioctl.h |4 ++
2 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index db2b231..29304c7 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1010,6 +1010,94 @@ out:
[...]
+ struct btrfs_ioctl_vol_args_v2 *vol_args;
+ int ret = 0;
+ u64 flags = 0;
+
+ if (inode-i_ino != BTRFS_FIRST_FREE_OBJECTID)
+ return -EINVAL;
+
+ vol_args = memdup_user(arg, sizeof(*vol_args));
Would be better to avoid a dynamic allocation for a so small struct ?
And as more general comment: what is the reason to pass a so complex struct
only for setting/getting the flags ?
Would be it better to pass directly a u64 variable.
[..]
+
+static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
+ void __user *arg)
+{
+ struct inode *inode = fdentry(file)-d_inode;
+ struct btrfs_root *root = BTRFS_I(inode)-root;
+ struct btrfs_trans_handle *trans;
+ struct btrfs_ioctl_vol_args_v2 *vol_args;
+ u64 root_flags;
+ u64 flags;
+ int ret = 0;
+
+ if (root-fs_info-sb-s_flags MS_RDONLY)
+ return -EROFS;
+
+ if (inode-i_ino != BTRFS_FIRST_FREE_OBJECTID)
+ return -EINVAL;
+
+ vol_args = memdup_user(arg, sizeof(*vol_args));
Same as before.
+ if (IS_ERR(vol_args))
+ return PTR_ERR(vol_args);
+ flags = vol_args-flags;
+
+ if (flags ~BTRFS_SUBVOL_RDONLY) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ down_write(root-fs_info-subvol_sem);
+
+ /* nothing to do */
+ if (!!(flags BTRFS_SUBVOL_RDONLY) == root-readonly)
+ goto out_unlock;
This is only an aesthetic comment: I prefer a simpler style like
if ((flags BTRFS_SUBVOL_RDONLY) root-readonly)
goto out_unlock;
But I know that every body has its style :-)
+
+ root_flags = btrfs_root_flags(root-root_item);
+ if (flags BTRFS_SUBVOL_RDONLY)
+ btrfs_set_root_flags(root-root_item,
+ root_flags | BTRFS_ROOT_SNAP_RDONLY);
+ else
+ btrfs_set_root_flags(root-root_item,
+ root_flags ~BTRFS_ROOT_SNAP_RDONLY);
+ root-readonly = !root-readonly;
I double checked this line. But if I read the code correctly I think that the
line above is wrong: the field root-readonly is flipped regardless the
value of the flags passed by the user.
Moreover I have another question: why internally the flags is
BTRFS_ROOT_SNAP_RDONLY, instead in user space the flag is BTRFS_SUBVOL_RDONLY
?
I suggest to
- rename BTRFS_SUBVOL_RDONLY in BTRFS_SUBVOL_CREATE_SNAP_RDONLY (like
BTRFS_SUBVOL_CREATE_SNAP_ASYNC)
- rename BTRFS_ROOT_SNAP_RDONLY in BTRFS_ROOT_FLAGS_RDONLY and use both in
userspace and in kernel space this flag. I suggested to remove SNAP because
the flag make sense also for a standard subvolume.
Gegards
G.Baroncelli
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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
[RFC] Improve btrfs subvolume find-new command
, subvol); return 12; } - ret = find_updated_files(fd, 0, last_gen); + ret = find_updated_files(fd, 0, last_gen, verbose); if (ret) return 19; return 0; diff --git a/btrfs_cmds.h b/btrfs_cmds.h index 7bde191..41372e7 100644 --- a/btrfs_cmds.h +++ b/btrfs_cmds.h @@ -20,6 +20,7 @@ int do_delete_subvolume(int nargs, char **argv); int do_create_subvol(int nargs, char **argv); int do_fssync(int nargs, char **argv); int do_defrag(int argc, char **argv); +int do_get_latest_gen(int argc, char **argv); int do_show_filesystem(int nargs, char **argv); int do_add_volume(int nargs, char **args); int do_balance(int nargs, char **argv); @@ -30,5 +31,6 @@ int do_subvol_list(int nargs, char **argv); int do_set_default_subvol(int nargs, char **argv); int list_subvols(int fd); int do_df_filesystem(int nargs, char **argv); -int find_updated_files(int fd, u64 root_id, u64 oldest_gen); +int find_updated_files(int fd, u64 root_id, u64 oldest_gen, int verbose); int do_find_newer(int argc, char **argv); +u64 find_root_gen(int fd); diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 26ef982..23ba7d2 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -15,6 +15,10 @@ btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBsubvolume set-default\fP\fI id path\fP .PP +\fBbtrfs\fP \fBsubvolume last-gen\fP\fI path\fP +.PP +\fBbtrfs\fP \fBsubvolume find-new\fP\fI path last_gen\fP +.PP \fBbtrfs\fP \fBfilesystem defrag\fP\fI file|dir [file|dir...]\fP .PP \fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP @@ -96,6 +100,21 @@ These ID may be used by the \fBsubvolume set-default\fR command, or at mount time via the \fIsubvol=\fR option. .TP +\fBsubvolume last-gen\fR\fI path\fR +Return the most current generation id of \fIpath\fR. This number is +suitable for use with the \fBsubvolume find-new\fR command, for example. +A single number is sent to stdout, representing the most recent generation +within a subvolume/snapshot. + +\fBsubvolume find-new\fR\fI path last_gen\fR +Display changes to the subvolume \fIpath\fR since the generation id +\fIlast_gen\fR. The resulting information includes filenames, offset +within the file, length, and more. The last line output displays the most +recent generation id represented by the output. For example, one could +feed this id back in to get an ongoing report of changes to the +subvolume. +.TP + \fBsubvolume set-default\fR\fI id path\fR Set the subvolume of the filesystem \fIpath\fR which is mounted as \fIdefault\fR. The subvolume is identified by \fBid\fR, which -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 signature.asc Description: This is a digitally signed message part.
Bug in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
Hi Li,
On Monday, 13 December, 2010, Li Zefan wrote:
The keys returned by tree search ioctl should be restricted to:
key.objectid = [min_objectid, max_objectid]
key.offset = [min_offset, max_offset]
key.type = [min_type, max_type]
But actually it returns those keys:
[(min_objectid, min_type, min_offset),
(max_objectid, max_type, max_offset)].
I have to admit that I had need several minutes to understand what you wrote
:). Then I came to conclusion that the tree search ioctl is basically wrong.
IMHO, the error in this API is to use the lower bound of the acceptance
criteria (the min_objectid, min_offset, min_type fields) also as starting
point for the search.
Let me explain with an example.
Suppose to want to search all the keys in the range
key.objectid = 10..20
key.offset = 100..200
key.type = 2..5
Suppose to set sk-nr_items to 1 for simplicity, and the keys available which
fit in the range are
1) [15,150,3]
2) [16,160,4]
3) [17,180,3]
All these key satisfy the acceptance criteria, but because we have to
restart the search from the last key found, the code should resemble
sk = args.key
sk-min_objectid=10; sk-max_objectid=20
sk-min_offset=100; sk-max_offset=200
sk-min_type=2; sk-max_type=5
sk-nr_items = 1;
while(1){
ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
if( !sk-nr_items )
break
for(off = 0, i=0 ; i sk-nr_items ; i ){
sh = (struct btrfs_ioctl_search_header *)(args.buf
off);
[...]
sk-min_objectid = sh-objectid;
sk-min_offset = sh-offset;
sk-min_type = sh-type;
}
increase the sk-min_* key of 1
}
But in this case, the code after found the key #2, sets the minimum acceptance
criteria to [16,160,4], which exclude the key #3 because min_type is too high.
Ideally, we should add three new field to the search key structure:
sk-start_objectid
sk-start_offset
sk-start_type
And after every iteration the code (even the kernel code) should set these
fields as last key found 1, leaving the min_* fields as they are.
My analysis is correct or I miss something ?
Regards
G.Baroncelli
And the bug can result in missing subvolumes in the output of
btrfs subvolume list
Reported-by: Ian! D. Allen idal...@idallen.ca
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/ioctl.c | 20
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index f1c9bb4..785f713 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1028,23 +1028,11 @@ out:
static noinline int key_in_sk(struct btrfs_key *key,
struct btrfs_ioctl_search_key *sk)
{
- struct btrfs_key test;
- int ret;
-
- test.objectid = sk-min_objectid;
- test.type = sk-min_type;
- test.offset = sk-min_offset;
-
- ret = btrfs_comp_cpu_keys(key, test);
- if (ret 0)
+ if (key-type sk-min_type || key-type sk-max_type)
return 0;
-
- test.objectid = sk-max_objectid;
- test.type = sk-max_type;
- test.offset = sk-max_offset;
-
- ret = btrfs_comp_cpu_keys(key, test);
- if (ret 0)
+ if (key-offset sk-min_offset || key-offset sk-max_offset)
+ return 0;
+ if (key-objectid sk-min_objectid || key-objectid sk-
max_objectid)
return 0;
return 1;
}
--
1.6.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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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 in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
On Tuesday, 14 December, 2010, Li Zefan wrote:
Goffredo Baroncelli wrote:
Hi Li,
On Monday, 13 December, 2010, Li Zefan wrote:
The keys returned by tree search ioctl should be restricted to:
key.objectid = [min_objectid, max_objectid]
key.offset = [min_offset, max_offset]
key.type = [min_type, max_type]
But actually it returns those keys:
[(min_objectid, min_type, min_offset),
(max_objectid, max_type, max_offset)].
I have to admit that I had need several minutes to understand what you
wrote
:). Then I came to conclusion that the tree search ioctl is basically
wrong.
IMHO, the error in this API is to use the lower bound of the acceptance
criteria (the min_objectid, min_offset, min_type fields) also as starting
point for the search.
Let me explain with an example.
Suppose to want to search all the keys in the range
key.objectid = 10..20
key.offset = 100..200
key.type = 2..5
Suppose to set sk-nr_items to 1 for simplicity, and the keys available
which
fit in the range are
1) [15,150,3]
2) [16,160,4]
3) [17,180,3]
All these key satisfy the acceptance criteria, but because we have to
restart the search from the last key found, the code should resemble
sk = args.key
sk-min_objectid=10; sk-max_objectid=20
sk-min_offset=100; sk-max_offset=200
sk-min_type=2; sk-max_type=5
sk-nr_items = 1;
while(1){
ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
if( !sk-nr_items )
break
for(off = 0, i=0 ; i sk-nr_items ; i ){
sh = (struct btrfs_ioctl_search_header *)(args.buf
off);
[...]
sk-min_objectid = sh-objectid;
sk-min_offset = sh-offset;
sk-min_type = sh-type;
}
increase the sk-min_* key of 1
}
But in this case, the code after found the key #2, sets the minimum
acceptance
criteria to [16,160,4], which exclude the key #3 because min_type is too
high.
Ideally, we should add three new field to the search key structure:
sk-start_objectid
sk-start_offset
sk-start_type
And after every iteration the code (even the kernel code) should set these
fields as last key found 1, leaving the min_* fields as they are.
My analysis is correct or I miss something ?
After looking more deeply, I found the ioctl was changed in this way
on purpose, to support btrfs subvolume find-new specifically.
See this commit:
commit abc6e1341bda974e2d0eddb75f57a20ac18e9b33
Author: Chris Mason chris.ma...@oracle.com
Date: Thu Mar 18 12:10:08 2010 -0400
Btrfs: fix key checks and advance in the search ioctl
The search ioctl was working well for finding tree roots, but using it
for
generic searches requires a few changes to how the keys are advanced.
This treats the search control min fields for objectid, type and offset
more like a key, where we drop the offset to zero once we bump the type,
etc.
The downside of this is that we are changing the min_type and min_offset
fields during the search, and so the ioctl caller needs extra checks to
make
the keys in the result are the ones it wanted.
This also changes key_in_sk to use btrfs_comp_cpu_keys, just to make
things more readable.
So I think we can just fix the btrfs tool. Though adding sk-start_xxx
should
also be able to meet the needs for btrfs subvolume find-new.
Sorry, but I have to disagree. This API seems to me simply bugged. The example
above (which is quite generic) highlights this fact. But I can provide a more
real case: suppose to use the BTRFS_IOC_TREE_SEARCH ioctl to find the new
files. We are interested to the following items:
- BTRFS_EXTENT_DATA_KEY (type = 1)
- BTRFS_INODE_ITEM_KEY (type = 24)
- BTRFS_XATTR_ITEM_KEY (type = 108)
Acceptance criteria:
min_type = 1
max_type = 108
min_offset = 0
max_offset = ~0
min_objectid = 0
max_objectid = ~0
min_transid = the base generation number
Pay attention that we aren't interested in the offset.
Suppose to have the following sequence keys [objectid, type, offset]:
[...]
1) [300, BTRFS_EXTENT_DATA_KEY, xx]
2) [300, BTRFS_INODE_ITEM_KEY, xx]
3) [300, BTRFS_XATTR_ITEM_KEY, xx]
4) [301, BTRFS_EXTENT_DATA_KEY, xx]
5) [301, BTRFS_INODE_ITEM_KEY, xx]
7) [30200, BTRFS_EXTENT_DATA_KEY, xx]
8) [30200, BTRFS_INODE_ITEM_KEY, xx]
9) [30200, BTRFS_XATTR_ITEM_KEY, xx]
[...]
Suppose that the buffer is filled between the item 2 and 3. We should restart
the search, but how set the min_
[PATCH] BTRFS_IOC_TREE_SEARCH: store and use the last key found
unused2;
__u64 unused3;
__u64 unused4;
};
@@ -182,7 +182,12 @@ struct btrfs_ioctl_space_args {
struct btrfs_ioctl_vol_args)
#define BTRFS_IOC_DEFRAG_RANGE _IOW(BTRFS_IOCTL_MAGIC, 16, \
struct btrfs_ioctl_defrag_range_args)
-#define BTRFS_IOC_TREE_SEARCH _IOWR(BTRFS_IOCTL_MAGIC, 17, \
+
+/* buggy, don't use */
+
+#define BTRFS_IOC_TREE_SEARCH_V0 _IOWR(BTRFS_IOCTL_MAGIC, 17, \
+ struct btrfs_ioctl_search_args)
+#define BTRFS_IOC_TREE_SEARCH_V1 _IOWR(BTRFS_IOCTL_MAGIC, 25, \
struct btrfs_ioctl_search_args)
#define BTRFS_IOC_INO_LOOKUP _IOWR(BTRFS_IOCTL_MAGIC, 18, \
struct btrfs_ioctl_ino_lookup_args)
[1] http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07513.html
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
signature.asc
Description: This is a digitally signed message part.
Re: Bug in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
On Wednesday, 15 December, 2010, Li Zefan wrote:
h4) objectid asis, type asis, offset++ - we should get the correct result.
This fix the problem of the missing subvolume. But for the other case
(searching for more than one type) the problem still here.
because the current ioctl uses min_{x,y,z} and max_{x,y,z} as start_key and
end_key, and it returns all keys that falls in [start_key, end_key].
So this btrfs-progs patch should fix missing subvolumes in the output of
subvolume list:
diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..1b9ea45 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -620,7 +620,10 @@ int list_subvols(int fd)
/* this iteration is done, step forward one root for the
next
* ioctl
*/
- if (sk-min_objectid (u64)-1) {
+ if (sk-min_type BTRFS_ROOT_BACKREF_KEY) {
+ sk-min_type = BTRFS_ROOT_BACKREF_KEY;
+ sk-min_offset = 0;
+ } else if (sk-min_objectid (u64)-1) {
sk-min_objectid++;
sk-min_type = BTRFS_ROOT_BACKREF_KEY;
sk-min_offset = 0;
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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 in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
On Wednesday, 15 December, 2010, Chris Mason wrote: Excerpts from Li Zefan's message of 2010-12-14 22:33:33 -0500: Suppose to have the following sequence keys [objectid, type, offset]: [...] 1)[300, BTRFS_EXTENT_DATA_KEY, xx] 2)[300, BTRFS_INODE_ITEM_KEY, xx] 3)[300, BTRFS_XATTR_ITEM_KEY, xx] 4)[301, BTRFS_EXTENT_DATA_KEY, xx] 5)[301, BTRFS_INODE_ITEM_KEY, xx] 7)[30200, BTRFS_EXTENT_DATA_KEY, xx] 8)[30200, BTRFS_INODE_ITEM_KEY, xx] 9)[30200, BTRFS_XATTR_ITEM_KEY, xx] [...] Suppose that the buffer is filled between the item 2 and 3. We should restart the search, but how set the min_* key ? Try the following hypothesis h1) objectid++, type = 0 - In the next search the key 3 would be skipped h2) objectid asis, type ++, - in the next search the key 4 would be skipped h3) objectid asis, type = 0 - in the next search the key 1,2,3 would be h4) objectid asis, type asis, offset++ - we should get the correct result. This is the right answer ;). The problem is that even though our key has 3 distinct parts, and the API makes it look like you have very fine grained control over those three parts, you have to remember to reset them as you iterate between objectids. It isn't a obvious as it should be. The current API is a very raw export of how we do the searches in the kernel too. You can do pretty much anything with it, but we pay with complexity. Hi Chris, I am a bit confused about your answer. The actual API is a bit confused (or almost not obvious). An application in order to work properly has to make some adjustment to the min_* fields AND filter the results (because if we tweak with the min_* field, not useful data is returned). Moreover this means that we move between user-space-kernel- space a lot of unused data (un-necessary context switch). On the basis of your answer, it seems that this is ok (please don't consider only the case of listing the subvolumes which is a very simple cases). And nothing have to do. Instead I suggest to (see my email [PATCH] BTRFS_IOC_TREE_SEARCH: store and use the last key found): - leave the min_* and max_* fields to act only as filter - add three more fields start_* as start point for the search - make some small modification to the kernel code to track in the start_* fields the last key found pro: - we pass to userspace only useful data - we simplify a lot the userspace application, because they don't have to update the min_* fields (they will work in a obvious way :-) ) - we can use the ordered property of a btree structure to perform efficient data lookup (if we reset to zero the min_* fields we lookup un-necessary data) - we have the same functionality of the old API cons: - we need a modification ( :-) ) May be that I missed some point, but I don't see any advantage to continue to support the actual API. Of course, that doesn't means that we can remove the old API ignoring the backward compatibility. But I think that there are sufficient pros to develop a new API Please be patient: my english is very bad; I am not trying to blame anybody; I want only a perfect fs (TM) :-) -chris -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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 in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
On Wednesday, 15 December, 2010, Li Zefan wrote:
Goffredo Baroncelli wrote:
On Wednesday, 15 December, 2010, Li Zefan wrote:
h4) objectid asis, type asis, offset++ - we should get the correct
result.
This fix the problem of the missing subvolume. But for the other case
(searching for more than one type) the problem still here.
I don't think so. And the above h4 has showed how we search for more
than one type.
The generic userland code for next search is:
/* this is in essence the same as how we advance key in kernel code */
if (sk-min_offset (u64)-1 sk-min_offset sk-max_offset)
sk-min_offset++;
else if (sk-min_type (u8)-1 sk-min_type sk-max_type) {
sk-min_offset = 0;
sk-min_type++;
} else if (sk-min_objectid (u64)-1 sk-min_objectid sk-
max_objectid){
sk-min_offset = 0;
sk-min_type = 0;
Sorry but if you reset the sk-min_type to 0, this means that the min_type
lost its purpose (act as lover bound of the acceptance criteria).
sk-min_objectid++;
} else
break;
ioctl(...);
for (i = 0; i nr_items; i++) {
if (!filter(items[i]))
continue;
So you are suggesting: Move all tree items from kernel to user space and
filter it in userspace ?. This mean a lot of un-needed kernel-space -
userspace transition...
Sorry I don't understand if we are talking about a workaround or a solution.
/* process this item */
...
}
because the current ioctl uses min_{x,y,z} and max_{x,y,z} as start_key
and
end_key, and it returns all keys that falls in [start_key, end_key].
So this btrfs-progs patch should fix missing subvolumes in the output of
subvolume list:
diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..1b9ea45 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -620,7 +620,10 @@ int list_subvols(int fd)
/* this iteration is done, step forward one root for the
next
* ioctl
*/
- if (sk-min_objectid (u64)-1) {
+ if (sk-min_type BTRFS_ROOT_BACKREF_KEY) {
+ sk-min_type = BTRFS_ROOT_BACKREF_KEY;
+ sk-min_offset = 0;
+ } else if (sk-min_objectid (u64)-1) {
sk-min_objectid++;
sk-min_type = BTRFS_ROOT_BACKREF_KEY;
sk-min_offset = 0;
--
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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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 in the design of the tree search ioctl API ? [was Re: [PATCH 1/3] Btrfs: Really return keys within specified range]
On Wednesday, 15 December, 2010, Chris Mason wrote: [...] Hi Chris, I am a bit confused about your answer. The actual API is a bit confused (or almost not obvious). An application in order to work properly has to make some adjustment to the min_* fields AND filter the results (because if we tweak with the min_* field, not useful data is returned). Moreover this means that we move between user-space- kernel- space a lot of unused data (un-necessary context switch). On the basis of your answer, it seems that this is ok (please don't consider only the case of listing the subvolumes which is a very simple cases). And nothing have to do. Well, it's ok in that I wanted the API to be very close to the way searches are done in the kernel. I'll definitely agree it isn't perfect, especially as we hop between objectids or types. But I don't want to extend it just yet, mostly because we don't have new applications making use of it. I'd rather couple any new apis with new applications that we haven't yet thought of. Thanks a lot for the time you're spending on review and looking at this. If you have killer apps that can really make use of new APIs, I'm happy to start reworking things. Look at a my previous email about an enhancement of the find-new command ([RFC] Improve btrfs subvolume find-new command - 11/12/2010). It would be sufficient ? (of course now on the basis of the last news of this API I know that this command is bugged :-( ) I can live with the current API ( tweaking the increasing of the min_* fields).. but think about another side of the question: now the only client of this API is the btrfs command (btrfs subvol list, which actually is broken) , and we can update this api with the minimum effort. Instead if we leave the current behavior in the future may appears an application which depends on it. So we may be obligated to maintain it .. Goffredo -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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: What do the arguments of btrfs filesystem defragment do?
On Wednesday, 15 December, 2010, Erik Logtenberg wrote: Hi, I would like to know that the arguments of btrfs filesystem defragment do. According to the built-in help page, the invocation is as follows: btrfs filesystem defragment [-vcf] [-s start] [-l len] [-t size] file|dir [file|dir...] Defragment a file or a directory. Unfortunately I can't find any documentation on the meaning of these arguments. The man page doesn't list these arguments: I loked at the code and I try to explain. But what I write below may be affected by error. If the parameter is a directory, the subvolume where the dir is placed is defragged. Instead if the parameter is a file, the switches have the following meaning: -f - flush after defrag -s - start point of defrag -l - length of defrag range (if len is = 0, the rest of file is considered) -c - force compress -t - threshold for compression (if the size of file is bigger, compress the file ?) -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Calling BTRFS_IOC_TREE_SEARCH for a non existant key
Hi all,
I discovered that when I call the BTRFS_IOC_TREE_SEARCH ioctl for a not
existent key, the ioctl requires a lot of time to be completed.
I tracks down the problem in the function search_ioctl(). It seems that the
function btrfs_search_forward() doesn't check if key is greater than max_key.
file ioctl.c
988 static noinline int search_ioctl(struct inode *inode,
989 struct btrfs_ioctl_search_args *args)
[...]
1025 while(1) {
1026 ret = btrfs_search_forward(root, key, max_key, path,
0,
1027 sk-min_transid);
1028 if (ret != 0) {
1029 if (ret 0)
1030 ret = 0;
1031 goto err;
1032 }
1033 ret = copy_to_sk(root, path, key, sk, args-buf,
1034 sk_offset, num_found);
1035 btrfs_release_path(root, path);
1036 if (ret || num_found = sk-nr_items)
1037 break;
1038 }
The function btrfs_search_forward() doesn't check the key (or min_key) against
max_key when the parameter cache_only == 0.
from ctree.c
3624 int btrfs_search_forward(struct btrfs_root *root, struct btrfs_key
*min_key,
3625 struct btrfs_key *max_key,
3626 struct btrfs_path *path, int cache_only,
3627 u64 min_trans)
3628 {
[..]
3678 if (!cache_only)
3679 break;
3680 if (max_key) {
3681 btrfs_node_key(cur, disk_key, slot);
3682 if (comp_keys(disk_key, max_key) =
0) {
3683 ret = 1;
3684 goto out;
3685 }
3686 }
So in the function search_ioctl the search is not completed until the args
buffer is filled or the function copy_to_sk detects that key is greater than
sk-max_*.
However the check performed by the function copy_to_sk is not always
sufficient to detect if a key is greater than sk-max_*. For example if
key.objectid sk-max_objectid but key.offset is sk-max_offset, the key is
supposed to be valid.
913 static noinline int copy_to_sk(struct btrfs_root *root,
[...]
970 }
971 advance_key:
972 ret = 0;
973 if (key-offset (u64)-1 key-offset sk-max_offset)
974 key-offset++;
975 else if (key-type (u8)-1 key-type sk-max_type) {
976 key-offset = 0;
977 key-type++;
978 } else if (key-objectid (u64)-1 key-objectid sk-
max_objectid) {
979 key-offset = 0;
980 key-type = 0;
981 key-objectid++;
982 } else
983 ret = 1;
984 overflow:
985 *num_found += found;
986 return ret;
987 }
To solve this problem it should be sufficient a key check before the call of
btrfs_search_forward().
But I don't know if this is a workaround or the root cause is inside the
function btrfs_search_forward() that doesn't check the key against max_key if
cached_only is 0.
Regards
G.Baroncelli
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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
[TRIVIAL][PATCH] Improve error handling in the btrfs command
Hi Chris,
below is enclosed a trivial patch, which has the aim to improve the error
reporting of the btrfs command.
You can pull from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
strerror
I changed every printf(some-error) to something like:
e = errno;
fprintf(stderr, ERROR: - %s, strerror(e));
so:
1) all the error are reported to standard error
2) At the end of the message is printed the error as returned by the system.
The change is quite simple, I replaced every printf(some-error) to the line
above. I don't touched anything other.
I also integrated a missing printf on the basis of the Ben patch.
This patch leads the btrfs command to be more user friendly :-)
Regards
G.Baroncelli
btrfs-list.c | 40 ++
btrfs_cmds.c | 77 -
utils.c |6
3 files changed, 89 insertions(+), 34 deletions(-)
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..abcc2f4 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -265,7 +265,7 @@ static int resolve_root(struct root_lookup *rl, struct root_info *ri)
static int lookup_ino_path(int fd, struct root_info *ri)
{
struct btrfs_ioctl_ino_lookup_args args;
- int ret;
+ int ret, e;
if (ri-path)
return 0;
@@ -275,9 +275,11 @@ static int lookup_ino_path(int fd, struct root_info *ri)
args.objectid = ri-dir_id;
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, args);
+ e = errno;
if (ret) {
- fprintf(stderr, ERROR: Failed to lookup path for root %llu\n,
- (unsigned long long)ri-ref_tree);
+ fprintf(stderr, ERROR: Failed to lookup path for root %llu - %s\n,
+ (unsigned long long)ri-ref_tree,
+ strerror(e));
return ret;
}
@@ -320,15 +322,18 @@ static u64 find_root_gen(int fd)
unsigned long off = 0;
u64 max_found = 0;
int i;
+ int e;
memset(ino_args, 0, sizeof(ino_args));
ino_args.objectid = BTRFS_FIRST_FREE_OBJECTID;
/* this ioctl fills in ino_args-treeid */
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, ino_args);
+ e = errno;
if (ret) {
- fprintf(stderr, ERROR: Failed to lookup path for dirid %llu\n,
- (unsigned long long)BTRFS_FIRST_FREE_OBJECTID);
+ fprintf(stderr, ERROR: Failed to lookup path for dirid %llu - %s\n,
+ (unsigned long long)BTRFS_FIRST_FREE_OBJECTID,
+ strerror(e));
return 0;
}
@@ -351,8 +356,10 @@ static u64 find_root_gen(int fd)
while (1) {
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+ e = errno;
if (ret 0) {
- fprintf(stderr, ERROR: can't perform the search\n);
+ fprintf(stderr, ERROR: can't perform the search - %s\n,
+strerror(e));
return 0;
}
/* the ioctl returns the number of item it found in nr_items */
@@ -407,14 +414,16 @@ static char *__ino_resolve(int fd, u64 dirid)
struct btrfs_ioctl_ino_lookup_args args;
int ret;
char *full;
+ int e;
memset(args, 0, sizeof(args));
args.objectid = dirid;
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, args);
+ e = errno;
if (ret) {
- fprintf(stderr, ERROR: Failed to lookup path for dirid %llu\n,
- (unsigned long long)dirid);
+ fprintf(stderr, ERROR: Failed to lookup path for dirid %llu - %s\n,
+ (unsigned long long)dirid, strerror(e) );
return ERR_PTR(ret);
}
@@ -472,6 +481,7 @@ static char *ino_resolve(int fd, u64 ino, u64 *cache_dirid, char **cache_name)
struct btrfs_ioctl_search_header *sh;
unsigned long off = 0;
int namelen;
+ int e;
memset(args, 0, sizeof(args));
@@ -490,8 +500,10 @@ static char *ino_resolve(int fd, u64 ino, u64 *cache_dirid, char **cache_name)
sk-nr_items = 1;
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+ e = errno;
if (ret 0) {
- fprintf(stderr, ERROR: can't perform the search\n);
+ fprintf(stderr, ERROR: can't perform the search - %s\n,
+ strerror(e));
return NULL;
}
/* the ioctl returns the number of item it found in nr_items */
@@ -550,6 +562,7 @@ int list_subvols(int fd)
char *name;
u64 dir_id;
int i;
+ int e;
root_lookup_init(root_lookup);
@@ -578,8 +591,10 @@ int list_subvols(int fd)
while(1) {
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+ e = errno;
if (ret 0) {
- fprintf(stderr, ERROR: can't perform the search\n);
+ fprintf(stderr, ERROR: can't perform the search - %s\n,
+strerror(e));
return ret;
}
/* the ioctl returns the number of item it found in nr_items */
@@ -747,6 +762,7 @@ int find_updated_files(int fd, u64 root_id, u64 oldest_gen)
u64 found_gen;
u64 max_found = 0;
int i;
+ int e;
u64 cache_dirid = 0;
u64 cache_ino = 0;
char *cache_dir_name = NULL;
@@ -773,8 +789,10 @@ int find_updated_files(int fd, u64 root_id, u64 oldest_gen)
max_found = find_root_gen(fd);
while(1) {
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+ e = errno;
if (ret 0) {
- fprintf(stderr
Re: [PATCH] Improve error handling in filesystem df
Hi Ben,
I integrated your patch on the my one (see my next email). However I changed
the argument of the strerror function from the ioctl return code to
the errno variable.
Regards
G.Baroncelli
On Sunday, 19 December, 2010, Ben Gamari wrote:
The return values of ioctl weren't being printed to stderr on failure,
causing the command to silently fail, resulting in a very confused
user.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
btrfs_cmds.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..45da2bd 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -857,6 +857,7 @@ int do_df_filesystem(int nargs, char **argv)
ret = ioctl(fd, BTRFS_IOC_SPACE_INFO, sargs);
if (ret) {
+ fprintf(stderr, ERROR: can't query '%s' for free space
(%s)\n, path, strerror(-ret));
free(sargs);
return ret;
}
@@ -875,6 +876,7 @@ int do_df_filesystem(int nargs, char **argv)
ret = ioctl(fd, BTRFS_IOC_SPACE_INFO, sargs);
if (ret) {
+ fprintf(stderr, ERROR: can't query '%s' for free space
(%s)\n, path, strerror(-ret));
free(sargs);
return ret;
}
--
1.7.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
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
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: [TRIVIAL][PATCH] Improve error handling in the btrfs command
On Monday, 20 December, 2010, you (Chris Samuel) wrote: On 21/12/10 07:06, Goffredo Baroncelli wrote: below is enclosed a trivial patch, which has the aim to improve the error reporting of the btrfs command. Any reason to not just use perror() ? Some time I needed to add other info, so perror(3) may not be sufficient.. -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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: Odd mkbtrfs behavior inside of chroot
On 01/02/2011 08:52 PM, J G wrote:
I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions while
using the latest btrfs-tools.
Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for the
backed up files and so I can update btrfs-tools
* Formatted/mounted/restored backup files to the temporary partition which I
mounted on /mnt/backup
* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today
(v0.19-35-g1b444cd-dirty).
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for the mount status. Now,
I'm no expert here, but I'm confused as to just why it failed. The last thing
of note:
lstat(/boot, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/boot/sysrcd.dat, 0x7fffb29681e0) = -1 ENOENT (No such file or
directory)
close(3)= 0
munmap(0x7f11df372000, 4096)= 0
write(2, error checking /dev/sda5 mount s..., 38error checking /dev/sda5
mount status
) = 38
doesn't explain much. I see that it's checking /proc/mounts to see what's
mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist
in the non-chrooted FS, btw).
To make this even weirder, if I format sda5/sdb5 using the SysRescCD version
of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it
works fine.
Any ideas here? I would expect that mkbtrfs would work inside of a chroot
without any assistance from the original root.
I have the full strace from the chrooted mkbtrfs failing and from it
succeeding, if that's helpful.
On the basis of the provided information, and on the code it seems that
mkfs.btrfs tries hard to check that the user is not formatting a mounted
disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every
devices. To do the check it needs to access the original file if this is
a loop backend. This is reasonable.
In this case in a chroot-ed environment the loop file is not accessible.
If you need a [dirty] quick hack to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a btrfs device scan
- mount the filesystem
Of course the right solution is to add a --force switch which
permits to by-pass these checks. Other mkfs.* tools have this switch.
From the mkfs.ext4 man page:
[...]
-F Force mke2fs to create a filesystem,
even if the specified device is not
a partition on a block special
device, or if other parameters do
not make sense. In order to force
mke2fs to create a filesystem even
if the filesystem appears to be in
use or is mounted (a truly dangerous
thing to do), this option must be
specified twice.
[...]
.:Justin:.
--
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] add a --force option to mkfs.btrf [was Re: Odd mkbtrfs behavior inside of chroot]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all and happy new year.
this is my first patch of the new year. Hooping that this is a good
sign. :-)
The enclosed patch try to address the problem raised by Justin: how
circumvent the check performed by mkfs.btrfs ?
I add a -f|--force switch which permits to bypass the check if a
device is already mounted. I update the man page too.
You can pull the change from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
force-mkfs
commit (2900a150cde604f82f1437c931792bfa59c4780b)
Comments are welcome
Regards
G.Baroncelli
- --
gpg key: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
On 01/03/2011 12:14 AM, Goffredo Baroncelli wrote:
On 01/02/2011 08:52 PM, J G wrote:
I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions while
using the latest btrfs-tools.
Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for the
backed up files and so I can update btrfs-tools
* Formatted/mounted/restored backup files to the temporary partition which I
mounted on /mnt/backup
* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today
(v0.19-35-g1b444cd-dirty).
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for the mount status. Now,
I'm no expert here, but I'm confused as to just why it failed. The last
thing of note:
lstat(/boot, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/boot/sysrcd.dat, 0x7fffb29681e0) = -1 ENOENT (No such file or
directory)
close(3)= 0
munmap(0x7f11df372000, 4096)= 0
write(2, error checking /dev/sda5 mount s..., 38error checking /dev/sda5
mount status
) = 38
doesn't explain much. I see that it's checking /proc/mounts to see what's
mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist
in the non-chrooted FS, btw).
To make this even weirder, if I format sda5/sdb5 using the SysRescCD version
of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it
works fine.
Any ideas here? I would expect that mkbtrfs would work inside of a chroot
without any assistance from the original root.
I have the full strace from the chrooted mkbtrfs failing and from it
succeeding, if that's helpful.
On the basis of the provided information, and on the code it seems that
mkfs.btrfs tries hard to check that the user is not formatting a mounted
disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every
devices. To do the check it needs to access the original file if this is
a loop backend. This is reasonable.
In this case in a chroot-ed environment the loop file is not accessible.
If you need a [dirty] quick hack to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a btrfs device scan
- mount the filesystem
Of course the right solution is to add a --force switch which
permits to by-pass these checks. Other mkfs.* tools have this switch.
From the mkfs.ext4 man page:
[...]
-F Force mke2fs to create a filesystem,
even if the specified device is not
a partition on a block special
device, or if other parameters do
not make sense. In order to force
mke2fs to create a filesystem even
if the filesystem appears to be in
use or is mounted (a truly dangerous
thing to do), this option must be
specified twice.
[...]
.:Justin:.
--
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
.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFNIh34vwTxYT3FBRIRAl1tAJ9k1LVUfahdlvLvK7b4gct55fom3QCfd1Ab
0JfVbWgKf7DXd0Gg1YzaPdU=
=Jt+e
-END PGP SIGNATURE-
diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 1e14c6c..f51291c 100644
--- a/man/mkfs.btrfs.8.in
+++ b/man/mkfs.btrfs.8.in
@@ -5,14 +5,14 @@ mkfs.btrfs \- create an btrfs filesystem
.B mkfs.btrfs
Re: Synching a Backup Server
On 01/06/2011 06:35 PM, Carl Cook wrote: I want to keep a duplicate copy of the HTPC data, on the backup server, and I think a regular full file copy is not optimal and may take days to do. So I'm looking for a way to sync the arrays at some interval. Ideally the sync would scan the HTPC with a CRC check to look for differences, copy over the differences, then email me on success. Is there a BTRFS tool that would do this? There is the command btrfs subvolume find-new which lists the file which have the data (but not the metadata) changed. But it is a very low level tool. I tried to enhance this command ( see a my post titled [RFC] Improve btrfs subvolume find-new command), but I never finished this work. Regards G.Baroncelli -- 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: Adding a disk fails
On 01/21/2011 12:10 AM, Carl Cook wrote: On Thu 20 January 2011 14:13:22 Goffredo Baroncelli wrote: To add another disk you don't have to run mkfs.btrfs. For example: # add the first disk mkfs.btrfs /dev/sdb # mount the disk mount /dev/sdb /media/backups # add another disk to the first one btrfs device add /dev/sdc /media/backup Thanks Goffredo but as I say, I did this and it responds with ERROR: error adding the device '/dev/sdc' .. it doesn't give a clue. In your email you wrote that before adding the device you format it. Anyway I don't think that this is the problem. Have you check which is reported in dmesg. Note1: the filesystem has to be mounted Note2: the medatada will be in raid1, the data in raid0 If you shutdown the system, at the reboot you should scan all the device in order to find the btrfs ones # find the btrfs device btrfs device scan This must be done at every boot? If so, where is recommended, in rc.local? Look at this thread, where I wrote anout a possible solution http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg04709.html # if you try to mount snapshot-3 directly, you fail because this # snapshot is not under the root of the btrfs filesystem mount -o subvol=dir-1/snapshot-3 /dev/sdb /media/backup # - error This is how I'd understood it, but when creating a subvolume in the root and putting a snalshot into it, it seems to make a further subvolume (or directory) with a redundant name. This would not be under the root, and may not be mountable? Which kenel version debian testing uses ? 2.6.32-5-amd64 with Debian patches. From a btrfs point of view, it is a very old kernel. IIRC in this kernel is not supported the snapshot removal. I suggest you to update the kernel with a recent one. btrfs filesystem snapshot / /snapshot-$(date +%Y-%m-%d) Oh thank you. -- 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: Backup Command
On 01/21/2011 08:07 PM, cac...@quantum-sci.com wrote: Well thanks to some help from you guys I seem to have my backup server almost fully running and functional with rsync. Amazing functions, this snapshotting and rsync. I still don't know why I cannot remove snapshots though. (Debian Testing with 2.6.32-28) I am not sure if the kernel 2.32 supports snapshot removal... And I don't know how to reach out from the backup server to the HTPC and stop MythTV there, so I can export the Mysql database safely, from a cron job on the backup server. Suggestions? -- 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 2/2] add detailed help messages to btrfs command
Hello Hubert,
please update the man page too.
Regards
G.Baroncelli
On 01/23/2011 01:42 PM, Hubert Kario wrote:
extend the
btrfs cmd --help
command to print detailed help message if available but fallback to
basic help message if detailed is unavailable
add detailed help message for 'filesystem defragment' command
little tweaks in comments
Signed-off-by: Hubert Kario ka...@wit.edu.pl
---
btrfs.c | 101 ++
1 files changed, 68 insertions(+), 33 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index b84607a..bd6f6f8 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -23,6 +23,9 @@
#include btrfs_cmds.h
#include version.h
+#define BASIC_HELP 0
+#define ADVANCED_HELP 1
+
typedef int (*CommandFunction)(int argc, char **argv);
struct Command {
@@ -31,8 +34,10 @@ struct Command {
if = 0, number of arguments,
if 0, _minimum_ number of arguments */
char*verb; /* verb */
- char*help; /* help lines; form the 2nd onward they are
-indented */
+ char*help; /* help lines; from the 2nd line onward they
+ are automatically indented */
+char*adv_help; /* advanced help message; from the 2nd line
+ onward they are automatically indented */
/* the following fields are run-time filled by the program */
char**cmds; /* array of subcommands */
@@ -47,73 +52,96 @@ static struct Command commands[] = {
{ do_clone, 2,
subvolume snapshot, source [dest/]name\n
Create a writable snapshot of the subvolume source with\n
- the name name in the dest directory.
+ the name name in the dest directory.,
+ NULL
},
{ do_delete_subvolume, 1,
subvolume delete, subvolume\n
- Delete the subvolume subvolume.
+ Delete the subvolume subvolume.,
+ NULL
},
{ do_create_subvol, 1,
subvolume create, [dest/]name\n
Create a subvolume in dest (or the current directory if\n
- not passed).
+ not passed).,
+ NULL
},
{ do_subvol_list, 1, subvolume list, path\n
- List the snapshot/subvolume of a filesystem.
+ List the snapshot/subvolume of a filesystem.,
+ NULL
},
{ do_find_newer, 2, subvolume find-new, path last_gen\n
- List the recently modified files in a filesystem.
+ List the recently modified files in a filesystem.,
+ NULL
},
{ do_defrag, -1,
filesystem defragment, [-vcf] [-s start] [-l len] [-t size]
file|dir [file|dir...]\n
- Defragment a file or a directory.
+ Defragment a file or a directory.,
+ [-vcf] [-s start] [-l len] [-t size] file|dir
[file|dir...]\n
+ Defragment file data or directory metadata.\n
+-v be verbose\n
+-c compress the file while defragmenting\n
+-f flush data to disk immediately after
defragmenting\n
+-s start defragment only from byte onward\n
+-l len defragment only up to len bytes\n
+-t sizeminimal size of file to be considered for
defragmenting\n
},
{ do_set_default_subvol, 2,
subvolume set-default, id path\n
Set the subvolume of the filesystem path which will be
mounted\n
- as default.
+ as default.,
+ NULL
},
{ do_fssync, 1,
filesystem sync, path\n
- Force a sync on the filesystem path.
+ Force a sync on the filesystem path.,
+ NULL
},
{ do_resize, 2,
filesystem resize, [+/-]newsize[gkm]|max filesystem\n
Resize the file system. If 'max' is passed, the filesystem\n
- will occupe all available space on the device.
+ will occupe all available space on the device.,
+ NULL
},
{ do_show_filesystem, 999,
filesystem show, [uuid|label]\n
Show the info of a btrfs filesystem. If no uuid or label\n
- is passed, info of all the btrfs filesystem are shown.
+ is passed, info of all the btrfs filesystem are shown.,
+ NULL
},
{ do_df_filesystem, 1,
filesystem df, path\n
- Show space usage information for a mount point\n.
+ Show space usage information for a mount point.,
+ NULL
},
{ do_balance, 1,
filesystem balance, path\n
- Balance the chunks across the device.
+ Balance the chunks across
Re: [PATCH 2/2] add detailed help messages to btrfs command
There are a lot of patches regarding the btrfs-tool.
Unfortunately, the btrfs maintainer are very busy in other areas of the
project. I don't know when (if) these patches will be applied.
However I think that is better have a misaligned patch instead nothing.
Regards
G.Baroncelli
On 01/23/2011 03:28 PM, Hubert Kario wrote:
On Sunday 23 of January 2011 15:07:09 Goffredo Baroncelli wrote:
Hello Hubert,
please update the man page too.
I started to do it but then I noticed that you have made a few changes to the
man page yourself.
I'm quite new to the git/mail patch system of releases and I'm not sure if I
should post the patch from my tree with your patch applied or not.
You have modified some of the same lines I want to fix and as such my patch
may not be cleanly applicable. So, which tree I should base my patch on?
Regards
Hubert Kario
On 01/23/2011 01:42 PM, Hubert Kario wrote:
extend the
btrfs cmd --help
command to print detailed help message if available but fallback to
basic help message if detailed is unavailable
add detailed help message for 'filesystem defragment' command
little tweaks in comments
Signed-off-by: Hubert Kario ka...@wit.edu.pl
---
btrfs.c | 101
++ 1 files
changed, 68 insertions(+), 33 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index b84607a..bd6f6f8 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -23,6 +23,9 @@
#include btrfs_cmds.h
#include version.h
+#define BASIC_HELP 0
+#define ADVANCED_HELP 1
+
typedef int (*CommandFunction)(int argc, char **argv);
struct Command {
@@ -31,8 +34,10 @@ struct Command {
if = 0, number of arguments,
if 0, _minimum_ number of arguments */
char*verb; /* verb */
- char*help; /* help lines; form the 2nd onward they are
- indented */
+ char*help; /* help lines; from the 2nd line onward they
+ are automatically indented */
+char*adv_help; /* advanced help message; from the 2nd
line + onward they are automatically
indented */
/* the following fields are run-time filled by the program */
char**cmds; /* array of subcommands */
@@ -47,73 +52,96 @@ static struct Command commands[] = {
{ do_clone, 2,
subvolume snapshot, source [dest/]name\n
Create a writable snapshot of the subvolume source with\n
- the name name in the dest directory.
+ the name name in the dest directory.,
+ NULL
},
{ do_delete_subvolume, 1,
subvolume delete, subvolume\n
- Delete the subvolume subvolume.
+ Delete the subvolume subvolume.,
+ NULL
},
{ do_create_subvol, 1,
subvolume create, [dest/]name\n
Create a subvolume in dest (or the current directory if\n
- not passed).
+ not passed).,
+ NULL
},
{ do_subvol_list, 1, subvolume list, path\n
- List the snapshot/subvolume of a filesystem.
+ List the snapshot/subvolume of a filesystem.,
+ NULL
},
{ do_find_newer, 2, subvolume find-new, path last_gen\n
- List the recently modified files in a filesystem.
+ List the recently modified files in a filesystem.,
+ NULL
},
{ do_defrag, -1,
filesystem defragment, [-vcf] [-s start] [-l len] [-t size]
file|dir [file|dir...]\n
- Defragment a file or a directory.
+ Defragment a file or a directory.,
+ [-vcf] [-s start] [-l len] [-t size] file|dir
[file|dir...]\n + Defragment file data or directory
metadata.\n
+-v be verbose\n
+-c compress the file while defragmenting\n
+-f flush data to disk immediately after
defragmenting\n +-s start defragment only from byte
onward\n +-l len defragment only up to len
bytes\n
+-t sizeminimal size of file to be considered for
defragmenting\n
},
{ do_set_default_subvol, 2,
subvolume set-default, id path\n
Set the subvolume of the filesystem path which will be
mounted\n
- as default.
+ as default.,
+ NULL
},
{ do_fssync, 1,
filesystem sync, path\n
- Force a sync on the filesystem path.
+ Force a sync on the filesystem path.,
+ NULL
},
{ do_resize, 2,
filesystem resize, [+/-]newsize[gkm]|max filesystem\n
Resize the file system. If 'max' is passed, the filesystem\n
Re: snapshot strange behaviour
On 01/23/2011 04:05 PM, Lubos Kolouch wrote: Goffredo Baroncelli, Sun, 23 Jan 2011 13:17:13 +0100: Hi Lubos, On 01/23/2011 08:17 AM, Lubos Kolouch wrote: Hello, Is this a bug or intended behaviour and I am missing something something? How to snapshot a subvolume, containing another subvolumes? It is the intended behavior. The snapshotting is not recursive about subvolumes. If you snapshot a subvolume which contains another one, you got only the content of the first subvolume. The directory x/b which you see, is not the subvolume b snapshotted, but only the mount-point of b. Hi Goffredo, I understand. But then I think btrfs should refuse to do it or at least print a warning. Otherwise it is very inconvenient for the user, having to search for any subvolumes down the tree... Sorry, but I can't agree. To me it seems a reasonable default. There are a lot of cases where I would not snapshot a sub-sub-subvolume: my rootfs is a subvolume, my home is in another one. I can snapshot, update the root fs, then if something goes wrong I can roolback to the old one, without affecting my home. This behavior is strictly related to the btrfs internal. Any way it is true that this behavior should be highlighted in the documentation. And more, it is possible to add a -R flag to snapshot recursively a subvolume... Goffredo Lubos -- 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: Bug in mkfs.btrfs?!
On 01/23/2011 07:18 PM, Hugo Mills wrote:
Hi, Felix,
On Sat, Jan 22, 2011 at 04:56:12PM +0100, Felix Blanke wrote:
It was a simple:
mkfs.btrfs -L backup -d single /dev/loop2
But it also happens without the options, like:
mkfs.btrfs /dev/loop2
/dev/loop2 is a loop device, which is aes encrypted. The output of losetup
/dev/loop2:
/dev/loop2: [0010]:5324
(/dev/disk/by-id/ata-WDC_WD6400AAKS-22A7B2_WD-WCASY7780706-part3)
encryption=AES128
Thanks you for looking into this!
While writing this I read your second mail. The strace output is attached.
OK, I've traced through the functions being called, and I really
can't see where it could be truncating the name, unless your system
has a stupidly small value of PATH_MAX.
It seems that when mkfs.btrfs checks if the passed block device is
already mounted, uses the ioctl LOOP_GET_STATUS [1]. This ioctl has as
argument the struct loop_info.
This ioctl, should return the info about the back-end of the loop
device. The file name is returned via the lo_name field, which is an
array of 64 char...[2]
Felix, what is the output of the following command ?
/sbin/losetup -a
If my analysis is correct, this command should return the filename
trunked at the 64th character too.
Goffredo
[1] file util.c, function resolve_loop_device
[2]
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L26
and
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux/loop.h?a=ppc#L15
Can you apply the following patch (to the next branch of the
btrfs-progs git repo), rebuild, and try again? It's just adding some
debugging output to track what it's looking at.
Hugo.
diff --git a/mkfs.c b/mkfs.c
index 2e99b95..51a5096 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -422,6 +422,7 @@ int main(int ac, char **av)
printf(WARNING! - see http://btrfs.wiki.kernel.org before using\n\n);
file = av[optind++];
+ printf(Checking whether %s is part of a mounted filesystem\n, file);
ret = check_mounted(file);
if (ret 0) {
fprintf(stderr, error checking %s mount status\n, file);
diff --git a/utils.c b/utils.c
index fd894f3..7fa3149 100644
--- a/utils.c
+++ b/utils.c
@@ -610,12 +610,16 @@ int resolve_loop_device(const char* loop_dev, char*
loop_file, int max_len)
int ret_ioctl;
struct loop_info loopinfo;
+ printf(Resolving loop device %s (length %d)\n, loop_dev, max_len);
+
if ((loop_fd = open(loop_dev, O_RDONLY)) 0)
return -errno;
ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, loopinfo);
close(loop_fd);
+ printf(Loop name = %s\n, loopinfo.lo_name);
+
if (ret_ioctl == 0)
strncpy(loop_file, loopinfo.lo_name, max_len);
else
@@ -639,6 +643,9 @@ int is_same_blk_file(const char* a, const char* b)
return -errno;
}
+ printf(Realpath of %s was %s\n, a, real_a);
+ printf(Realpath of %s was %s\n, b, real_b);
+
/* Identical path? */
if(strcmp(real_a, real_b) == 0)
return 1;
@@ -680,6 +687,9 @@ int is_same_loop_file(const char* a, const char* b)
const char* final_b;
int ret;
+ printf(is_same_loop_file: %s and %s\n, a, b);
+ printf(PATH_MAX = %d\n, PATH_MAX);
+
/* Resolve a if it is a loop device */
if((ret = is_loop_device(a)) 0) {
return ret;
@@ -784,8 +794,10 @@ int check_mounted(const char* file)
if(strcmp(mnt-mnt_type, btrfs) != 0)
continue;
+ printf(Testing if btrfs device is in the dev list:
%s\n, mnt-mnt_fsname);
ret = blk_file_in_dev_list(fs_devices_mnt,
mnt-mnt_fsname);
} else {
+ printf(Testing if non-btrfs device is block or
regular: %s\n, mnt-mnt_fsname);
/* ignore entries in the mount table that are not
associated with a file*/
if((ret = is_existing_blk_or_reg_file(mnt-mnt_fsname))
0)
diff --git a/volumes.c b/volumes.c
index 7671855..2496fbd 100644
--- a/volumes.c
+++ b/volumes.c
@@ -130,6 +130,8 @@ static int device_list_add(const char *path,
device-fs_devices = fs_devices;
}
+ printf(Device added with name %s\n, device-name);
+
if (found_transid fs_devices-latest_trans) {
fs_devices-latest_devid = devid;
fs_devices-latest_trans = found_transid;
@@ -223,6 +225,7 @@ int btrfs_scan_one_device(int fd, const char *path,
*total_devs = btrfs_super_num_devices(disk_super);
uuid_unparse(disk_super-fsid, uuidbuf);
+ printf(Adding device %s to list\n, path);
ret = device_list_add(path, disk_super, devid, fs_devices_ret);
error_brelse:
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
Re: [RFC][PATCH] Btrfs: New inode number allocator
On 01/26/2011 02:53 AM, Li Zefan wrote: Here comes the compatability issue. It's fine to mount old btrfs, because we'll just use the original way to find free ino. But we can't mount new btrfs in older kernels, because the OFFSET makes highest objectid overflow when it is cast to unsigned long in 32bits system. We can store ino extents to a seperate btree, and then the new btrfs can be mounted in older kernels, but another problem will arise when remounting it in new kernels - creating new files will probably fail (but not oops) because the ino extent items are not consistent with inode items. If the above behavior (failing to create files) is not acceptable, we'll have to add an incompat flag. I can't comment the patch from a technical point of view. However I want to add a my comment about the compatibility issues. I remember that Linus was not happy about a filesystem which is not compatible when the the kernel version decrease. IIRC during the switch from ext3 to ext4 there were some issues during a git bis-sect process. So my suggestions are: - don't allow that an automatic switch to the new inode allocation policy. It should be the user to force this switch ( via a mount option for example) - in case the performance regression are noticeable, allow the user to use the old policy, which, if I understood correctly, work fine on a 64 bit system [*]. Regards G.Baroncelli [*] Supposing to create continuously 1000 file per sec, it needs 2^64/1000 sec = ~ 573.000.000 years to exhaust all the available inode numbers. -- 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-progs use safe string manipulation functions
On 02/07/2011 01:22 PM, Eduardo Silva wrote: Please find the attached patch which replace unsafe strcpy(3) by strncpy(3) functions. regards, Eduardo Silva Hi Eduardo, even though some strncpy are unneeded because a check is performed before, I fully agree that strncpy is better than a simple strcpy. However I have to highlight that truncating a path without noticing may be lead to a problem (think a delete operation applied to a shorter path...). So can I ask you to add some checks to your patch, in order to warn the user that the path is too long ? Regards G.Baroncelli -- 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: mkfs.btrfs - error checking /dev/sda5 mount status
On 02/09/2011 09:12 PM, Lubos Kolouch wrote: Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100: On 02/08/2011 10:26 PM, Lubos Kolouch wrote: Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100: On 02/08/2011 07:57 AM, Lubos Kolouch wrote: Hi, I'm hitting this issue - sda5 is a normal device, nothing to do with loop, encryption etc. # mkfs.btrfs /dev/sda5 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using error checking /dev/sda5 mount status Is there something I can do to resolve this? Some months ago I posted a patch [*] which allows to create a filesystem even if an integrity tests fail. Anyway it would be interesting understand why mkfs.btrfs fails. It is possible to have a strace of the command ? here ... http://paste.pocoo.org/show/334638/ but it is not in chroot, it is in normal system Lubos Hi Lubos, Could you post also the output of cat /proc/mounts command and the output of btrfs filesystem show command. I cannot understand what should be the problem. Hi Goffredo, Sure, # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / btrfs rw,noatime,compress,ssd 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=217934,mode=755 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0 none /var/tmp/portage tmpfs rw,relatime 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0 /dev/mapper/_dev_sda6 /home btrfs rw,noatime,compress,ssd 0 0 # btrfs filesystem show Label: none uuid: fd070c17-e98b-4b50-9fa8-3453482aafa2 Total devices 1 FS bytes used 5.51GB devid1 size 18.64GB used 10.79GB path /dev/sda2 Label: none uuid: bf9a1b00-f8bd-44d3-b140-10eea088a60e Total devices 1 FS bytes used 6.73GB devid1 size 19.54GB used 19.54GB path /dev/sda5 Label: none uuid: ae0ba016-1945-4e7a-9fb4-e9311d199727 Total devices 1 FS bytes used 57.50GB devid1 size 78.91GB used 78.91GB path /dev/dm-0 # mkfs.btrfs /dev/sda5 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using error checking /dev/sda5 mount status Also, I can mount it no problem - strange, isn't it Ok, I think to have track down the problem. To me it seems a bug in mkfs.btrfs. The first thing that should be highlighted is that you are trying to format an already btrfs formatted device. In this there is not anything wrong. However, before formatting a device mkfs.btrfs performs some sanity check. It checks if the device is already mounted, scanning /proc/mounts. In a normal case (the device which will be formatted doesn't contain a btrfs filesystem), mkfs.btrfs is smart enough to don't check device which are in /proc/mounts bat doesn't exist (like /dev/root). Instead when the device which will be formatted already contains a btrfs filesystem, mkfs.btrfs performs a different checks. In fact it considers also the case of a multi-device based btrfs filesystem. However in this case it doesn't skip a not existent device but it raises an error. I think that this is a bug. As workaround I suggest the following: make a link between the real root device and /dev/root. It should be sufficient to format the device. Lubos -- 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-progs use safe string manipulation functions
On 02/10/2011 02:29 PM, Eduardo Silva wrote:
On Thu, 2011-02-10 at 12:39 +0100, Olaf van der Spek wrote:
On Thu, Feb 10, 2011 at 12:37 PM, Jeremy Sanders
jer...@jeremysanders.net wrote:
Olaf van der Spek wrote:
On Thu, Feb 10, 2011 at 12:08 PM, Thomas Bellman bell...@nsc.liu.se
wrote:
strncpy(args.name, source, BTRFS_PATH_NAME_MAX);
args.name[BTRFS_PATH_NAME_MAX] = '\0';
That's silly. Isn't there a sane safe variant of strcpy?
There's strlcpy, but it's not in glibc because of possible truncation
errors!
Then use a private wrapper.
Here's the new patch:
[PATCH] Add safe string manipulation functions
Deprecate direct use of strcpy(3)
The following string manipulation function has been added:
- string_copy() : wrapper of strcpy(3)
- string_ncopy(): wrapper of strncpy(3)
both function compose safe NULL terminated strings.
I check that the code most of the time raise an error if the path is too
long, so the new wrappers should be ok...
best,
Eduardo Silva
[...]
+char *string_copy(char *dest, const char *src)
+{
+ if (!dest || !src) {
+ fprintf(stderr, ERROR: invalid string_copy() parameters);
+ exit(EXIT_FAILURE);
+ }
+
+ memset(dest, '\0', sizeof(dest));
What is the purpose of the line above ? sizeof(dest) is a const value
(typically 4 or 8) !
I agree with Olaf that string_copy() is usefulness.
I suggest you to improve the check of the string length before the copy
(not in the copy function), and raising an error when the length of the
string is too long.
Regards
G.Baroncelli
--
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: Comparing snapshots?
On 02/25/2011 10:59 AM, Arvin Schnell wrote: Hi, for a backup program I have to find all differing files (including metadata) in two snapshots taken from the same subvolume. Having looked at the find-new command I thought about this process: 1. Get the two transids when the two snapshots were created. 2. Query modifications to the original subvolume between the two transids. Is the general process corrent or have I overseen something? I suppose that you are thinking to something like: - record the last trans-id (trans-id1) - update the file-system - [...] - record the last trans-id (trans-id2) - update the file-system - [...] - Backup all the objects which have a trans-id between (trans-id1-trans-id2] This may lead to miss two kinds of operations 1) a file deletion 2) a file changed two times, the first one after the first snapshot, and the second one after the second snapshot. In the first case you would not be able to find any key update between the two trans-id(s), because they simply doesn't exist. In the second case the trans-id associated to the object is after trans-id2. For solving the point two you must change Query modifications to the original subvolume into Query modifications to the second snapshot. This means that the second snapshot must exist (it is not sufficient to know the trans-id).. For solving the point one, it is needed to a) track the change not only of the files but also of the directory (if you remove a file, the timestamp of the directory inode is updated). b) compare the update directories with the original ones. This means that the first snapshot must exist (it is not sufficient to know the trans-id). I have to point out that for a backup purpose would be sufficient to track the changed files (and not the deleted ones). I started to develop a tool to comparing two snapshot. But I stopped when I discovered that the ioctl BTRFS_IOC_TREE_SEARCH was not robust enough for that: when I tried to find the changed inode, attribute, extended attribute... I discovered that the ioctl BTRFS_IOC_TREE_SEARCH don't work well is some corner case [*]. I even tried to propose a patch to mitigate the problem. But at the time the develop efforts were (are) oriented to other issues, and the patch was not merged.. However if you want to start to develop something, I can go deeper in the problem. [*] see the thread Bug in the design of the tree search ioctl API ?, http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07523.html AFAIS the btrfs tool does not provide the required information/commands. Would it be possible to add those? Thanks in advance, Arvin -- 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: Comparing snapshots?
On 02/25/2011 08:32 PM, João Eduardo Luís wrote: Hello, Please note that my experience with btrfs is both recent and, above all, very small. However, I've been wondering about the same issue for a different purpose and your question intrigues me. However, and I may be off-base here, I think that wouldn't be trivial to achieve. Even if one would be able to differ the metadata changes between both snapshots, the problem would still be present regarding finding the changed data. It would be possible to check for changed extents, at least by comparing extent checksums, but I don't think it would be trivial to discover where (exactly) the extent was modified. Look at the find-new command. It returns also which part of the file is changed. I don't remember very well the details, but also the data is stored in a tree like the metadata. Using the same strategies of comparing the keys and revid leads to discover which part of the file is changed, with minimum effort (no checksums comparing is needed). I would recommend using the generation fields, whenever applicable, but I believe these are private to each subvolume/snapshot. Anyway, I wonder if keeping a data structure (I would go with a tree) containing metadata regarding the changed files, within the file system, could be a plausible solution, but I'm in no condition (btrfs-knowledge-wise) to make such statement. Cheers. --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu On Feb 25, 2011, at 9:59 AM, Arvin Schnell wrote: Hi, for a backup program I have to find all differing files (including metadata) in two snapshots taken from the same subvolume. Having looked at the find-new command I thought about this process: 1. Get the two transids when the two snapshots were created. 2. Query modifications to the original subvolume between the two transids. Is the general process corrent or have I overseen something? AFAIS the btrfs tool does not provide the required information/commands. Would it be possible to add those? Thanks in advance, Arvin -- Arvin Schnell, aschn...@suse.de Senior Software Engineer, Research Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- 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: drives with more than 2 TByte
On 03/24/2011 05:43 PM, Helmut Hullen wrote: Hallo, linux-btrfs, what about disks with more than 2 TByte? Other filesystems (?) need GPT. The filesystems don't care about the partition system. The 2TB limits is related to the maximum partition size. Of course a filesystem cannot be greater the partition where it is allocated. When I use mkfs.btrfs /dev/sdc (p.e. with drive sdc), does that work without problems with btrfs? It should. BTW, why you dont' use a GPT partition table ? Viele Gruesse! Helmut -- 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: minor ID for btrfs-control
Hello Helmut,
On 04/03/2011 05:11 AM, Helmut Hullen wrote:
Hallo, Goffredo,
[..]
As wrote by Tomasz the minor number of the btrfs-control is allocated
dynamically.
At which place?
I replied you too fast. Btrfs register a misc device, but its number
is not dynamically allocated (see [1] for further information), but it
is static.
$ grep BTRFS_MINOR -r include/
include/linux/miscdevice.h:#define BTRFS_MINOR 234
I can conclude that _now_ the minor is 234 and not 55. But I don't know
if it is a _stable_ interface.
I think that during the boot you should check the minor with
grep btrfs-control /proc/misc | awk '{ print $1 }'
Regards
G.Baroncelli
[1] http://www.linuxjournal.com/article/2920
Viele Gruesse!
Helmut
--
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 subvolume fake mount problem when default subvolume is set
Hi
On 04/06/2011 11:34 AM, Zhong, Xin wrote:
We create two subvolumes (meego_root and meego_home) in
btrfs root directory. And set meego_root as default mount
subvolume. After we remount btrfs, meego_root is mounted
to top directory by default. Then if we create a directory with
the same name as meego_home, we can mount meego_home subvolume
sucessfully (subvol=meego_home). But this is incorrect. What we
do in this mount point will not change anything in meego_home
subvolume. The problem is when default mount subvolume is set to
meego_root, we search meego_home in meego_root. But if we find a
directory with the same name, we will treat it as subvolume. So
the solution is to check if what we find is really a subvolume.
I think that this a bug, so a warning should be raised. We had a lot of
problem because btrfsctl -s did the same thing: if we referred to a
directory, they snapshot the directory's subvolume and the user didn't
understood what happened.
Personally I prefer that in case a wrong option the kernel raises a
warning and stops, not that it makes a choice about which default is
more reasonable.
Reagrds
G.Baroncelli
Signed-off-by: Zhong, Xin xin.zh...@intel.com
---
fs/btrfs/super.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index b85fe78..66a76b7 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -823,7 +823,9 @@ static int btrfs_get_sb(struct file_system_type *fs_type,
int flags,
error = PTR_ERR(new_root);
goto error_free_subvol_name;
}
- if (!new_root-d_inode) {
+ if (!new_root-d_inode ||
+ /* new_root is a directory, not subvolume */
+ new_root-d_inode-i_ino != BTRFS_FIRST_FREE_OBJECTID) {
dput(root);
dput(new_root);
deactivate_locked_super(s);
--
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 1/5] Add support for read-only subvolumes.
Hi Andreas,
On 04/25/2011 03:47 PM, Andreas Philipp wrote:
Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
btrfs_cmds.c | 44
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..baec675 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -43,7 +43,7 @@
#ifdef __CHECKER__
It is not related to your parch.. but does anyone know why we re-define
some constants if __CHECKER__ is defined ?
#define BLKGETSIZE64 0
-#define BTRFS_IOC_SNAP_CREATE 0
+#define BTRFS_IOC_SNAP_CREATE_V2 0
#define BTRFS_VOL_NAME_MAX 255
struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX]; };
static inline int ioctl(int fd, int define, void *arg) { return 0; }
@@ -310,13 +310,34 @@ int do_subvol_list(int argc, char **argv)
int do_clone(int argc, char **argv)
{
char*subvol, *dst;
- int res, fd, fddst, len;
+ int res, fd, fddst, len, optind = 0, readonly = 0;
char*newname;
char*dstdir;
- subvol = argv[1];
- dst = argv[2];
- struct btrfs_ioctl_vol_args args;
+ while(1) {
+ int c = getopt(argc, argv, r);
+ if (c 0)
+ break;
+ switch(c) {
+ case 'r':
+ optind++;
+ readonly = 1;
+ break;
+ default:
+ fprintf(stderr, Invalid arguments for
subvolume snapshot\n);
+ free(argv);
+ return 1;
+ }
+ }
+ if (argc - optind 2) {
+ fprintf(stderr, Invalid arguments for defragment\n);
May be that you need to replace defragment with subvolume snapshot ?
+ free(argv);
+ return 1;
+ }
+
+ subvol = argv[optind+1];
+ dst = argv[optind+2];
+ struct btrfs_ioctl_vol_args_v2 args;
Does the standard C allow to define a variable in the middle in a
function instead of in the begin ?
Anyway, even not required, I suggest to fill args by zero.
+ memset(args, 0, sizeog(args));
res = test_issubvolume(subvol);
if(res0){
@@ -371,12 +392,19 @@ int do_clone(int argc, char **argv)
fprintf(stderr, ERROR: can't access to '%s'\n, dstdir);
return 12;
}
+
+ if (readonly) {
+ args.flags |= BTRFS_SUBVOL_RDONLY;
+ printf(Create a readonly snapshot of '%s' in '%s/%s'\n,
+subvol, dstdir, newname);
+ }
+ else
+ printf(Create a snapshot of '%s' in '%s/%s'\n,
+subvol, dstdir, newname);
It is not required, but I suggest to use also in the else the brackets
( {} ).
- printf(Create a snapshot of '%s' in '%s/%s'\n,
-subvol, dstdir, newname);
args.fd = fd;
strcpy(args.name, newname);
- res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, args);
+ res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_V2, args);
close(fd);
close(fddst);
Regards
G.Baroncelli
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot resize btrfs volume
Hi, several time ago I posted a patch which addressed this lack of documentation [1]. Unfortunately when I revised this patch I missed this chunk, and now Chris merged the last (uncompleted) revision. So now I am publish a new patch which address this issue. Chris, if you want you can pull it from http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git or browse it at http://cassiopea.homelinux.net/git/?p=btrfs-progs-unstable.git;a=summary;. Below the patch. Regards G.Baroncelli diff --git a/man/btrfs.8.in b/man/btrfs.8.in index 6f92f91..220bcbd 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -147,7 +147,7 @@ Force a sync for the filesystem identified by \fIpath\fR. .\ Some wording are extracted by the resize2fs man page .\ -\fBfilesystem resize\fR\fI [+/\-]size[gkm]|max path\fR +\fBfilesystem resize\fR\fI [devid:][+/\-]size[gkm]|max path\fR Resize a filesystem identified by \fIpath\fR. The \fIsize\fR parameter specifies the new size of the filesystem. If the prefix \fI+\fR or \fI\-\fR is present the size is increased or decreased @@ -164,6 +164,9 @@ The \fBresize\fR command \fBdoes not\fR manipulate the size partition. If you wish to enlarge/reduce a filesystem, you must make sure you can expand the partition before enlarging the filesystem and shrink the partition after reducing the size of the filesystem. + +devid is the ID of the device which was enlarged or which will be reduced. +To know the ID of a device use the command \fBbtrfs filesystem show\fR. .TP \fBbtrfs\fP \fBfilesystem label\fP\fI dev [newlabel]\fP @@ -188,7 +191,7 @@ Show the btrfs filesystem with some additional info. If no U passed, \fBbtrfs\fR show info of all the btrfs filesystem. .TP -\fBdevice balance\fR \fIpath\fR +\fBfilesystem balance\fR \fIpath\fR Balance the chunks of the filesystem identified by \fIpath\fR across the devices. .TP @@ -199,6 +202,7 @@ Add device(s) to the filesystem identified by \fIpath\fR. \fBdevice delete\fR\fI dev [dev..] path\fR Remove device(s) from a filesystem identified by \fIpath\fR. + .PP .SH EXIT STATUS [1] email Re: [PATCH][btrfs progs] Update/clean up btrfs help and man page on 10/9/2010 On 05/04/2011 10:41 AM, Lubos Kolouch wrote: Hello again, OK I found it (randomly) on the wiki: btrfs filesystem resize 3:max /home Seems like btrfs help is not up-to-date and the wiki is... Thank you again Lubos Lubos Kolouch, Wed, 04 May 2011 08:31:30 +: Hello, I added a new disk into our RAID5 array, it looks like this: md2 : active raid5 sdd4[3] sde4[4] sda4[0] sdc4[2] sdb4[1] 3767274240 blocks level 5, 64k chunk, algorithm 2 [5/5] [U] # btrfs fi sh Label: none uuid: 5534d2e7-be31-49c7-8ab7-90c5ab8afe18 Total devices 1 FS bytes used 2.24TB devid3 size 2.63TB used 2.63TB path /dev/md2 # mount ... /dev/md2 on /home type btrfs (rw,noatime,compress) # btrfs filesystem resize max /home Resize '/home' of 'max' ERROR: unable to resize '/home' # umount /home/ # btrfs filesystem resize max /dev/md2 Resize '/dev/md2' of 'max' ERROR: unable to resize '/dev/md2' # tail /var/log/messages May 4 10:28:57 localhost kernel: resizer unable to find device 1 2.6.38-gentoo-r3, latest git btrfs-progs Can you please advice what to do? Thank you Lubos -- 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 filesystem label command
Hi, I suppose that you are familiar with 'git' and the standard unix command (like cd, make...). The quick way is the following: $ cd /tmp $ git clone -b label \ http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git $ cd btrfs-progs-unstable.git $ make $ ./btrfs Hoping that this may help you Regards G.Baroncelli On 05/09/2011 11:36 PM, BJ Quinn wrote: Hi, Sorry to ask what's probably a painfully obvious question, but I'd like to use your btrfs filesystem label command. For the life of me, I can't quite figure out what the process would be to download the btrfs-progs sources and apply your patch and use the command. Can you point me in the right direction? Thanks! -BJ Quinn -- 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 filesystem label command
On 05/11/2011 09:15 PM, BJ Quinn wrote: Thanks! I had to install libuuid-devel (Fedora) to get past an error not being able to find uuid.h when running make. It works perfectly. This seems like such a basic functionality, have they accepted your patches? Do you know if this is going to get merged? Yes, this patch was merged and is in the tmp branch of the main btrfs-prog git repository [*]. Unfortunately this brach doesn't even compile (or almost it gives me an error). I don't know when it will be available. Regards G.Baroncelli [*] http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=commit;h=d1dc6a9cff7e2fe4f335ca783a4b033457b3e184 -BJ From: Goffredo Baroncelli kreij...@inwind.it To: BJ Quinn b...@placs.net Cc: linux-btrfs@vger.kernel.org Sent: Tuesday, May 10, 2011 1:18:04 PM Subject: Re: btrfs filesystem label command Hi, I suppose that you are familiar with 'git' and the standard unix command (like cd, make...). The quick way is the following: $ cd /tmp $ git clone -b label \ http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git $ cd btrfs-progs-unstable.git $ make $ ./btrfs Hoping that this may help you Regards G.Baroncelli On 05/09/2011 11:36 PM, BJ Quinn wrote: Hi, Sorry to ask what's probably a painfully obvious question, but I'd like to use your btrfs filesystem label command. For the life of me, I can't quite figure out what the process would be to download the btrfs-progs sources and apply your patch and use the command. Can you point me in the right direction? Thanks! -BJ Quinn -- 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: [Validation] How to properly use the subvolume and snapshot for a backup method
On 05/25/2011 05:49 AM, Sylvain Alain wrote: Hi everyone, first of all, I want to say that I'm learning how to use BTRFS and I really enjoy all the subvolume and the snapshot features. Also, I'm a backup freak :P Basically, I have 4 questions : 1. I would like to know what is the best way to install a Linux distribution inside a BTRFS partition ? I mean, do I install it directly inside the subvolid=0 or I create a subvolume for exemple @root to leave the subvolid=0 clean and without any data, of course only subvolume and then I install my distro inside the @root subvolume ? I'm asking that, because I saw that Ubuntu 11.04 use the subvolume @ and @home to install the distribution files so, the subvolid=0 is clean. I saw that because at boot time, the /boot/grub/grub.cfg use this param with Grub2 : rootflags=subvol=@ I do so 2. I would like to know if this Live backup method is correct ? + My /dev/sda2 contains a @root subvolume that contains my distribution, my /home directory is inside an another subvolume that is at the same level that @root. # mkdir /mnt/disklayout # mount /dev/sda2 /mnt/disklayout -o subvolid=0 # cd /mnt/disklayout # btrfs subvolume snapshot @root snapshot-@racine-live # btrfs subvolume snapshot @home snapshot-@home-live # mount /dev/sdb1 /mnt/backup -o subvol=@backup # time rsync -aHA --del --force --stats --progress snapshot-@racine-live/ /mnt/backup/funtoo # time rsync -aHA --del --force --stats --progress snapshot-@home-live/ /mnt/backup/funtoo/home # time rsync -aHA --del --force --stats --progress /boot/ /mnt/backup/funtoo/boot # cd /mnt/disklayout # btrfs subvolume delete snapshot-@root-live # btrfs subvolume delete snapshot-@home-live # cd / # umount /mnt/disklayout Creation of the snapshot : # cd / # umount /mnt/backup # mount /dev/sdb1 /mnt/backup -o subvolid=0 # cd /mnt/backup # btrfs subvolume snapshot @backup @snap-20110502 # btrfs subvolume list . # cd /mnt/backup # ls -la # cd @snap-20110502 # ls -la # cd / # umount /mnt/backup to me it seems correctly -- 3. Is there any objection to use a snapshot name or a subvolume that start with a @ ? 4. Finally,I would like to know if we can rename subvolume ? I did without trouble The best example is this : I crash my box but I made earlier a snapshot that is named @snap-20110502 inside my subvolid=0. Now that my @root is brain dead, I would like to delete it and rename the @snap-20110502 to @root ? Is this possible and if so, can I use the mv command or something else ? I'm sure that I will need to boot with a LiveCD to do so, but for the rest, is this possible ? I tweaked a bit the grub script (under /etc/grub.d/);now when I run update-grub, the grub.cfg contains also some entries which permit do boot in the snapshot subvolume. Basycally these entries contains the replace the parameter rootflags=subvol=@ in rootflags=subvol=subvolume name. Is far to be optimal, but doing so I don't need any LiveCD. For example in a snapshot I am testing systemd ... Thanks you very much !!! -- 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/5][REPOST][BTRFS-PROGS] Be more verbose when a ioctl returns an error
Hi Hugo,
I tryed to rebase this patch on your repo, but it seem that it was
already applied. (see commit b3007332100e01ca84c161b6c75f0a414ab4611b)...
Let me know how to proceede
Regards
G.Baroncelli
On 06/12/2011 11:51 PM, Hugo Mills wrote:
Goffredo -
This is missing a S-o-B, and is damaged with line-wrapping. If you
fix it up and re-send, I can pull into my integration branch so it
doesn't get forgotten...
Hugo.
On Sun, Dec 05, 2010 at 06:47:38PM +0100, Goffredo Baroncelli wrote:
Hi all,
this patch makes the command btrfs more verbose when a btrfs ioctl return
an
error. The error code is printed as text message by the strerror(errno)
function.
Example:
# btrfs subvol create /tmp/1
Create subvolume '/tmp/1'
# btrfs subvol create /tmp/1/2
Create subvolume '/tmp/1/2'
# btrfs subvol delete
$ sudo btrfs subvol delete /tmp/1
Delete subvolume '/tmp/1'
ERROR: cannot delete '/tmp/1' - Directory not empty
You can pull the patch also from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
strerror
Comments are welcome.
Reagrds
G.Baroncelli
diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..abcc2f4 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -265,7 +265,7 @@ static int resolve_root(struct root_lookup *rl, struct
root_info *ri)
static int lookup_ino_path(int fd, struct root_info *ri)
{
struct btrfs_ioctl_ino_lookup_args args;
-int ret;
+int ret, e;
if (ri-path)
return 0;
@@ -275,9 +275,11 @@ static int lookup_ino_path(int fd, struct root_info *ri)
args.objectid = ri-dir_id;
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, args);
+e = errno;
if (ret) {
-fprintf(stderr, ERROR: Failed to lookup path for root
%llu\n,
-(unsigned long long)ri-ref_tree);
+fprintf(stderr, ERROR: Failed to lookup path for root %llu -
%s\n,
+(unsigned long long)ri-ref_tree,
+strerror(e));
return ret;
}
@@ -320,15 +322,18 @@ static u64 find_root_gen(int fd)
unsigned long off = 0;
u64 max_found = 0;
int i;
+int e;
memset(ino_args, 0, sizeof(ino_args));
ino_args.objectid = BTRFS_FIRST_FREE_OBJECTID;
/* this ioctl fills in ino_args-treeid */
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, ino_args);
+e = errno;
if (ret) {
-fprintf(stderr, ERROR: Failed to lookup path for dirid
%llu\n,
-(unsigned long long)BTRFS_FIRST_FREE_OBJECTID);
+fprintf(stderr, ERROR: Failed to lookup path for dirid %llu -
%s\n,
+(unsigned long long)BTRFS_FIRST_FREE_OBJECTID,
+strerror(e));
return 0;
}
@@ -351,8 +356,10 @@ static u64 find_root_gen(int fd)
while (1) {
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+e = errno;
if (ret 0) {
-fprintf(stderr, ERROR: can't perform the search\n);
+fprintf(stderr, ERROR: can't perform the search -
%s\n,
+strerror(e));
return 0;
}
/* the ioctl returns the number of item it found in nr_items
*/
@@ -407,14 +414,16 @@ static char *__ino_resolve(int fd, u64 dirid)
struct btrfs_ioctl_ino_lookup_args args;
int ret;
char *full;
+int e;
memset(args, 0, sizeof(args));
args.objectid = dirid;
ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, args);
+e = errno;
if (ret) {
-fprintf(stderr, ERROR: Failed to lookup path for dirid
%llu\n,
-(unsigned long long)dirid);
+fprintf(stderr, ERROR: Failed to lookup path for dirid %llu -
%s\n,
+(unsigned long long)dirid, strerror(e) );
return ERR_PTR(ret);
}
@@ -472,6 +481,7 @@ static char *ino_resolve(int fd, u64 ino, u64
*cache_dirid, char
**cache_name)
struct btrfs_ioctl_search_header *sh;
unsigned long off = 0;
int namelen;
+int e;
memset(args, 0, sizeof(args));
@@ -490,8 +500,10 @@ static char *ino_resolve(int fd, u64 ino, u64
*cache_dirid, char
**cache_name)
sk-nr_items = 1;
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
+e = errno;
if (ret 0) {
-fprintf(stderr, ERROR: can't perform the search\n);
+fprintf(stderr, ERROR: can't perform the search - %s\n,
+strerror(e));
return NULL;
}
/* the ioctl returns the number of item it found in nr_items */
@@ -550,6 +562,7 @@ int list_subvols(int fd)
char *name;
u64 dir_id;
int i;
+int e;
root_lookup_init(root_lookup);
@@ -578,8 +591,10 @@ int list_subvols(int fd)
while(1
[RFC][BTRFS-PROG] Avoid to scan cdrom and floppy
Hi all,
thanks to the last Hugo's email, I restart to work on the patch which
avoid to scan cdrom and floppy during a btrfs filesystem show and a
btrfs device scan. Comparing to my previous patch I modified the
strategy, and now the scan of the devices is based on the content of the
file /proc/partitions. The old behavior may be set passing the
--all-devices options.
I resend as RFC, because this change may be incompatible with the old
behavior. Frankly speaking I don't see any problem, but I think that it
is better to discuss in the mailing list.
You can pull the patch also from
http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git
branch
scan-proc-partitions
Comment are welcome
The diff is computed against the Hugo's repository
btrfs.c|4 +-
btrfs_cmds.c | 47
man/btrfs.8.in | 26 +++-
utils.c| 58 +
utils.h|2 +
5 files changed, 120 insertions(+), 17 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index 87cc680..c6ae692 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -104,7 +104,7 @@ static struct Command commands[] = {
NULL
},
{ do_show_filesystem, 999,
- filesystem show, [device|uuid|label]\n
+ filesystem show, [--all-devices][uuid|label]\n
Show the info of a btrfs filesystem. If no argument\n
is passed, info of all the btrfs filesystem are shown.,
NULL
@@ -157,7 +157,7 @@ static struct Command commands[] = {
Cancel the balance operation running on path.
},
{ do_scan,
- 999, device scan, [device [device..]\n
+ 999, device scan, [--all-devices|device [device..]\n
Scan all device for or the passed device for a btrfs\n
filesystem.,
NULL
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 062e7d7..21b1dd5 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -590,11 +590,29 @@ int do_fssync(int argc, char **argv)
int do_scan(int argc, char **argv)
{
int i, fd, e;
- if(argc=1){
+ int checklist = 1;
+ int devstart = 1;
+
+ if( argc = 2 !strcmp(argv[1],--all-devices)){
+
+ if( argc 2 ){
+ fprintf(stderr, ERROR: too may arguments\n);
+return 22;
+}
+
+ checklist = 0;
+ devstart += 1;
+ }
+
+ if(argc=devstart){
+
int ret;
printf(Scanning for Btrfs filesystems\n);
ghigo@venice:~/btrfs/btrfs-progs-unstable$ git diff
integration-hugo-mills | cat
diff --git a/btrfs.c b/btrfs.c
index 87cc680..c6ae692 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -104,7 +104,7 @@ static struct Command commands[] = {
NULL
},
{ do_show_filesystem, 999,
- filesystem show, [device|uuid|label]\n
+ filesystem show, [--all-devices][uuid|label]\n
Show the info of a btrfs filesystem. If no argument\n
is passed, info of all the btrfs filesystem are shown.,
NULL
@@ -157,7 +157,7 @@ static struct Command commands[] = {
Cancel the balance operation running on path.
},
{ do_scan,
- 999, device scan, [device [device..]\n
+ 999, device scan, [--all-devices|device [device..]\n
Scan all device for or the passed device for a btrfs\n
filesystem.,
NULL
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 062e7d7..21b1dd5 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -590,11 +590,29 @@ int do_fssync(int argc, char **argv)
int do_scan(int argc, char **argv)
{
int i, fd, e;
- if(argc=1){
+ int checklist = 1;
+ int devstart = 1;
+
+ if( argc = 2 !strcmp(argv[1],--all-devices)){
+
+ if( argc 2 ){
+ fprintf(stderr, ERROR: too may arguments\n);
+return 22;
+}
+
+ checklist = 0;
+ devstart += 1;
+ }
+
+ if(argc=devstart){
+
int ret;
printf(Scanning for Btrfs filesystems\n);
- ret = btrfs_scan_one_dir(/dev, 1);
+ if(checklist)
+ ret = btrfs_scan_block_devices(1);
+ else
+ ret = btrfs_scan_one_dir(/dev, 1);
if (ret){
fprintf(stderr, ERROR: error %d while
scanning\n, ret);
return 18;
@@ -608,7 +626,7 @@ int do_scan(int argc, char **argv)
return 10;
}
- for( i = 1 ; i argc ; i++ ){
+ for( i = devstart ; i argc ; i++ ){
struct btrfs_ioctl_vol_args args;
int ret;
@@ -731,14 +749,33 @@ int do_show_filesystem(int argc, char **argv)
struct list_head
Re: [RFC][BTRFS-PROG] Avoid to scan cdrom and floppy
Hi Helmut On 06/16/2011 05:09 PM, Helmut Hullen wrote: Hallo, Josef, Du meintest am 16.06.11: Who the hell doesn't use udev? Me - p.e. udev may be interesting for desktop users, for multimedia computers. It's not necessary for a simple server, for a machine where the administrator wants to rule instead of udev. You don't need udev to use btrfs, I've just not seen a distro that allows you to not run with udev, so my question is more curiosity than anything. But the developers seem to use only machines where udev runs. p.e. when testing the disks (I've told this bug about 1 year ago), p.e. with /dev/btrfs-control. btrfs-control has to exist before btrfs is started, and there is neither a hint in the documentation nor a check. Sorry Helmut, but I don't understand if you are blaming about lack of documentation or about a problem. The fact that the file /dev/btrfs-control doesn't exist, is not a bug/problem of btrfs. This file should be created by the distribution: or via the udev or via devtmpfs or statically. In this is not different by any other device (like /dev/sdaX for example). They have to exists before mounting the root-filesystem. BR G.Baroncelli -- 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][v4] Enhance btrfs fi df
pverwflow (thanks to Zach to highlight it) - adding the sla_pretty_sizes() function to remove the call of string_list_add() from df_pretty_sizes. v4 2014/02/13 - Rebased to v3.12 - Replace MB/GB/TB with MiB/GiB/TiB - correct some small bug related to mixing same raid level with different disk number -removing the string_list_add() function -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 1/8] Enhance the command btrfs filesystem df.
Enhance the command btrfs filesystem df to show space usage information
for a mount point(s). It shows also an estimation of the space available,
on the basis of the current one used.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
Makefile | 3 +-
cmds-fi-disk_usage.c | 516 +++
cmds-fi-disk_usage.h | 25 +++
cmds-filesystem.c| 91 +
ctree.h | 17 +-
utils.c | 13 ++
utils.h | 2 +
7 files changed, 575 insertions(+), 92 deletions(-)
create mode 100644 cmds-fi-disk_usage.c
create mode 100644 cmds-fi-disk_usage.h
diff --git a/Makefile b/Makefile
index 0874a41..db470b6 100644
--- a/Makefile
+++ b/Makefile
@@ -13,7 +13,8 @@ objects = ctree.o disk-io.o radix-tree.o extent-tree.o
print-tree.o \
cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
cmds-quota.o cmds-qgroup.o cmds-replace.o cmds-check.o \
- cmds-restore.o cmds-rescue.o chunk-recover.o super-recover.o
+ cmds-restore.o cmds-rescue.o chunk-recover.o super-recover.o \
+ cmds-fi-disk_usage.o
libbtrfs_objects = send-stream.o send-utils.o rbtree.o btrfs-list.o crc32c.o \
uuid-tree.o
libbtrfs_headers = send-stream.h send-utils.h send.h rbtree.h btrfs-list.h \
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
new file mode 100644
index 000..4012c78
--- /dev/null
+++ b/cmds-fi-disk_usage.c
@@ -0,0 +1,516 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/ioctl.h
+#include errno.h
+
+#include utils.h
+#include kerncompat.h
+#include ctree.h
+
+#include commands.h
+
+#include version.h
+
+#define DF_HUMAN_UNIT (10)
+
+/*
+ * To store the size information about the chunks:
+ * the chunks info are grouped by the tuple (type, devid, num_stripes),
+ * i.e. if two chunks are of the same type (RAID1, DUP...), are on the
+ * same disk, have the same stripes then their sizes are grouped
+ */
+struct chunk_info {
+ u64 type;
+ u64 size;
+ u64 devid;
+ u64 num_stripes;
+};
+
+/*
+ * Pretty print the size
+ * PAY ATTENTION: it return a statically buffer
+ */
+static char *df_pretty_sizes(u64 size, int mode)
+{
+ static char buf[30];
+
+ if (mode DF_HUMAN_UNIT)
+ (void)pretty_size_snprintf(size, buf, sizeof(buf));
+ else
+ sprintf(buf, %llu, size);
+
+ return buf;
+}
+
+/*
+ * Add the chunk info to the chunk_info list
+ */
+static int add_info_to_list(struct chunk_info **info_ptr,
+ int *info_count,
+ struct btrfs_chunk *chunk)
+{
+
+ u64 type = btrfs_stack_chunk_type(chunk);
+ u64 size = btrfs_stack_chunk_length(chunk);
+ int num_stripes = btrfs_stack_chunk_num_stripes(chunk);
+ int j;
+
+ for (j = 0 ; j num_stripes ; j++) {
+ int i;
+ struct chunk_info *p = 0;
+ struct btrfs_stripe *stripe;
+ u64devid;
+
+ stripe = btrfs_stripe_nr(chunk, j);
+ devid = btrfs_stack_stripe_devid(stripe);
+
+ for (i = 0 ; i *info_count ; i++)
+ if ((*info_ptr)[i].type == type
+ (*info_ptr)[i].devid == devid
+ (*info_ptr)[i].num_stripes == num_stripes ) {
+ p = (*info_ptr) + i;
+ break;
+ }
+
+ if (!p) {
+ int size = sizeof(struct btrfs_chunk) * (*info_count+1);
+ struct chunk_info *res = realloc(*info_ptr, size);
+
+ if (!res) {
+ fprintf(stderr, ERROR: not enough memory\n);
+ return -1;
+ }
+
+ *info_ptr = res;
+ p = res + *info_count;
+ (*info_count)++;
+
+ p-devid = devid;
+ p-type = type;
+ p-size = 0;
+ p-num_stripes = num_stripes
[PATCH 2/8] Create the man page entry for the command btrfs fi df
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it --- man/btrfs.8.in | 52 1 file changed, 52 insertions(+) diff --git a/man/btrfs.8.in b/man/btrfs.8.in index b620348..4acf16d 100644 --- a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -35,6 +35,9 @@ btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBfilesystem label\fP [\fIdevice\fP|\fImount_point\fP] [\fInewlabel\fP] .PP +\fBbtrfs\fP \fBfilesystem df\fP\fI [-b] \fIpath [path..]\fR\fP +.PP +\fBbtrfs\fP \fBfilesystem balance\fP\fI path \fP .PP \fBbtrfs\fP \fB[filesystem] balance start\fP [\fIoptions\fP] \fIpath\fP .PP @@ -370,6 +373,55 @@ force reducing of metadata integrity \fB[filesystem] balance pause\fR\fI path\fR Pause running balance. + +.RE +.TP + +\fBfilesystem df\fP [-b] \fIpath [path..]\fR + +Show space usage information for a mount point. + +\fB-b\fP Set byte as unit + +The command \fBbtrfs filesystem df\fP is used to query how many space on the +disk(s) are used and an estimation of the free +space of the filesystem. +The output of the command \fBbtrfs filesystem df\fP shows: + +.RS +.IP \fBDisk\ size\fP +the total size of the disks which compose the filesystem. + +.IP \fBDisk\ allocated\fP +the size of the area of the disks used by the chunks. + +.IP \fBDisk\ unallocated\fP +the size of the area of the disks which is free (i.e. +the differences of the values above). + +.IP \fBUsed\fP +the portion of the logical space used by the file and metadata. + +.IP \fBFree\ (estimated)\fP +the estimated free space available: i.e. how many space can be used +by the user. The evaluation +cannot be rigorous because it depends by the allocation policy (DUP, Single, +RAID1...) of the metadata and data chunks. If every chunk is stored as +Single the sum of the \fBfree (estimated)\fP space and the \fBused\fP +space is equal to the \fBdisk size\fP. +Otherwise if all the chunk are mirrored (raid1 or raid10) or duplicated +the sum of the \fBfree (estimated)\fP space and the \fBused\fP space is +half of the \fBdisk size\fP. Normally the \fBfree (estimated)\fP is between +these two limits. + +.IP \fBData\ to\ disk\ ratio\fP +the ratio betwen the \fBlogical size\fP (i.e. the space available by +the chunks) and the \fBdisk allocated\fP (by the chunks). Normally it is +lower than 100% because the metadata is duplicated for security reasons. +If all the data and metadata are duplicated (or have a profile like RAID1) +the \fBData\ to\ disk\ ratio\fP could be 50%. + +.RE .TP \fB[filesystem] balance cancel\fR\fI path\fR -- 1.8.5.3 -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 5/8] Add command btrfs filesystem disk-usage
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
cmds-fi-disk_usage.c | 428 +++
cmds-fi-disk_usage.h | 3 +
cmds-filesystem.c| 3 +
utils.c | 63
utils.h | 3 +
5 files changed, 500 insertions(+)
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
index 4012c78..16b3ab2 100644
--- a/cmds-fi-disk_usage.c
+++ b/cmds-fi-disk_usage.c
@@ -20,10 +20,12 @@
#include unistd.h
#include sys/ioctl.h
#include errno.h
+#include stdarg.h
#include utils.h
#include kerncompat.h
#include ctree.h
+#include string_table.h
#include commands.h
@@ -44,6 +46,13 @@ struct chunk_info {
u64 num_stripes;
};
+/* to store information about the disks */
+struct disk_info {
+ u64 devid;
+ charpath[BTRFS_DEVICE_PATH_NAME_MAX];
+ u64 size;
+};
+
/*
* Pretty print the size
* PAY ATTENTION: it return a statically buffer
@@ -514,3 +523,422 @@ int cmd_filesystem_df(int argc, char **argv)
return 0;
}
+/*
+ * Helper to sort the disk_info structure
+ */
+static int cmp_disk_info(const void *a, const void *b)
+{
+ return strcmp(((struct disk_info *)a)-path,
+ ((struct disk_info *)b)-path);
+}
+
+/*
+ * This function load the disk_info structure and put them in an array
+ */
+static int load_disks_info(int fd,
+ struct disk_info **disks_info_ptr,
+ int *disks_info_count)
+{
+
+ int ret, i, ndevs;
+ struct btrfs_ioctl_fs_info_args fi_args;
+ struct btrfs_ioctl_dev_info_args dev_info;
+ struct disk_info *info;
+
+ *disks_info_count = 0;
+ *disks_info_ptr = 0;
+
+ ret = ioctl(fd, BTRFS_IOC_FS_INFO, fi_args);
+ if (ret 0) {
+ fprintf(stderr, ERROR: cannot get filesystem info\n);
+ return -1;
+ }
+
+ info = malloc(sizeof(struct disk_info) * fi_args.num_devices);
+ if (!info) {
+ fprintf(stderr, ERROR: not enough memory\n);
+ return -1;
+ }
+
+ for (i = 0, ndevs = 0 ; i = fi_args.max_id ; i++) {
+
+ BUG_ON(ndevs = fi_args.num_devices);
+ ret = get_device_info(fd, i, dev_info);
+
+ if (ret == -ENODEV)
+ continue;
+ if (ret) {
+ fprintf(stderr,
+ ERROR: cannot get info about device devid=%d\n,
+ i);
+ free(info);
+ return -1;
+ }
+
+ info[ndevs].devid = dev_info.devid;
+ strcpy(info[ndevs].path, (char *)dev_info.path);
+ info[ndevs].size = get_partition_size((char *)dev_info.path);
+ ++ndevs;
+ }
+
+ BUG_ON(ndevs != fi_args.num_devices);
+ qsort(info, fi_args.num_devices,
+ sizeof(struct disk_info), cmp_disk_info);
+
+ *disks_info_count = fi_args.num_devices;
+ *disks_info_ptr = info;
+
+ return 0;
+
+}
+
+/*
+ * This function computes the size of a chunk in a disk
+ */
+static u64 calc_chunk_size(struct chunk_info *ci)
+{
+ if (ci-type BTRFS_BLOCK_GROUP_RAID0)
+ return ci-size / ci-num_stripes;
+ else if (ci-type BTRFS_BLOCK_GROUP_RAID1)
+ return ci-size ;
+ else if (ci-type BTRFS_BLOCK_GROUP_DUP)
+ return ci-size ;
+ else if (ci-type BTRFS_BLOCK_GROUP_RAID5)
+ return ci-size / (ci-num_stripes -1);
+ else if (ci-type BTRFS_BLOCK_GROUP_RAID6)
+ return ci-size / (ci-num_stripes -2);
+ else if (ci-type BTRFS_BLOCK_GROUP_RAID10)
+ return ci-size / ci-num_stripes;
+ return ci-size;
+}
+
+/*
+ * This function print the results of the command btrfs fi disk-usage
+ * in tabular format
+ */
+static void _cmd_filesystem_disk_usage_tabular(int mode,
+ struct btrfs_ioctl_space_args *sargs,
+ struct chunk_info *chunks_info_ptr,
+ int chunks_info_count,
+ struct disk_info *disks_info_ptr,
+ int disks_info_count)
+{
+ int i;
+ u64 total_unused = 0;
+ struct string_table *matrix = 0;
+ int ncols, nrows;
+
+ ncols = sargs-total_spaces + 2;
+ nrows = 2 + 1 + disks_info_count + 1 + 2;
+
+ matrix = table_create(ncols, nrows);
+ if (!matrix) {
+ fprintf(stderr, ERROR: not enough memory\n);
+ return;
+ }
+
+ /* header */
+ for (i = 0; i sargs-total_spaces; i++) {
+ const char *description;
+
+ u64 flags = sargs-spaces[i].flags;
+ description = group_type_str(flags);
+
+ table_printf(matrix, 1+i, 0, %s
[PATCH 4/8] Allow use of get_device_info()
Allow the use of get_device_info() for different units.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
utils.c | 2 +-
utils.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index 760db6b..69295b5 100644
--- a/utils.c
+++ b/utils.c
@@ -1591,7 +1591,7 @@ void close_file_or_dir(int fd, DIR *dirstream)
close(fd);
}
-static int get_device_info(int fd, u64 devid,
+int get_device_info(int fd, u64 devid,
struct btrfs_ioctl_dev_info_args *di_args)
{
int ret;
diff --git a/utils.h b/utils.h
index 0f7939c..58fb4a7 100644
--- a/utils.h
+++ b/utils.h
@@ -97,4 +97,6 @@ int btrfs_scan_lblkid(int update_kernel);
int get_btrfs_mount(const char *dev, char *mp, size_t mp_size);
u64 disk_size(char *path);
+int get_device_info(int fd, u64 devid,
+ struct btrfs_ioctl_dev_info_args *di_args);
#endif
--
1.8.5.3
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 3/8] Add helpers functions to handle the printing of data in tabular format.
This patch adds some functions to manage the printing of the data in
tabular format.
The function
struct string_table *table_create(int columns, int rows)
creates an (empty) table.
The functions
char *table_printf(struct string_table *tab, int column,
int row, char *fmt, ...)
char *table_vprintf(struct string_table *tab, int column,
int row, char *fmt, va_list ap)
populate the table with text. To align the text to the left, the text
shall be prefixed with '', otherwise the text shall be prefixed by a
''. If the first character is a '=', the the text is replace by a
sequence of '=' to fill the column width.
The function
void table_free(struct string_table *)
frees all the data associated to the table.
The function
void table_dump(struct string_table *tab)
prints the table on stdout.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
Makefile | 2 +-
string_table.c | 156 +
string_table.h | 36 +
3 files changed, 193 insertions(+), 1 deletion(-)
create mode 100644 string_table.c
create mode 100644 string_table.h
diff --git a/Makefile b/Makefile
index db470b6..5738379 100644
--- a/Makefile
+++ b/Makefile
@@ -9,7 +9,7 @@ CFLAGS = -g -O1 -fno-strict-aliasing
objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
root-tree.o dir-item.o file-item.o inode-item.o inode-map.o \
extent-cache.o extent_io.o volumes.o utils.o repair.o \
- qgroup.o raid6.o free-space-cache.o list_sort.o
+ qgroup.o raid6.o free-space-cache.o list_sort.o string_table.o
cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
cmds-quota.o cmds-qgroup.o cmds-replace.o cmds-check.o \
diff --git a/string_table.c b/string_table.c
new file mode 100644
index 000..016356c
--- /dev/null
+++ b/string_table.c
@@ -0,0 +1,156 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#include stdlib.h
+#include string.h
+#include stdio.h
+#include stdarg.h
+
+#include string_table.h
+
+/*
+ * This function create an array of char * which will represent a table
+ */
+struct string_table *table_create(int columns, int rows)
+{
+ struct string_table *p;
+ int size;
+
+ size = sizeof( struct string_table ) +
+ rows * columns* sizeof(char *);
+ p = calloc(1, size);
+
+ if (!p) return NULL;
+
+ p-ncols = columns;
+ p-nrows = rows;
+
+ return p;
+}
+
+/*
+ * This function is like a vprintf, but store the results in a cell of
+ * the table.
+ * If fmt starts with '', the text is left aligned; if fmt starts with
+ * '' the text is right aligned. If fmt is equal to '=' the text will
+ * be replaced by a '=' dimensioned on the basis of the column width
+ */
+char *table_vprintf(struct string_table *tab, int column, int row,
+ char *fmt, va_list ap)
+{
+ int idx = tab-ncols*row+column;
+ char *msg = calloc(100, sizeof(char));
+
+ if (!msg)
+ return NULL;
+
+ if (tab-cells[idx])
+ free(tab-cells[idx]);
+ tab-cells[idx] = msg;
+ vsnprintf(msg, 99, fmt, ap);
+
+ return msg;
+}
+
+
+/*
+ * This function is like a printf, but store the results in a cell of
+ * the table.
+ */
+char *table_printf(struct string_table *tab, int column, int row,
+ char *fmt, ...)
+{
+ va_list ap;
+ char *ret;
+
+ va_start(ap, fmt);
+ ret = table_vprintf(tab, column, row, fmt, ap);
+ va_end(ap);
+
+ return ret;
+}
+
+/*
+ * This function dumps the table. Every = string will be replaced by
+ * a === length as the column
+ */
+void table_dump(struct string_table *tab)
+{
+ int sizes[tab-ncols];
+ int i, j;
+
+ for (i = 0 ; i tab-ncols ; i++) {
+ sizes[i] = 0;
+ for (j = 0 ; j tab-nrows ; j++) {
+ int idx = i + j*tab-ncols;
+ int s;
+
+ if (!tab-cells[idx])
+ continue;
+
+ s = strlen(tab-cells[idx]) - 1;
+ if (s 1 || tab-cells[idx][0
[PATCH 7/8] Add btrfs device disk-usage command
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
cmds-device.c| 3 ++
cmds-fi-disk_usage.c | 136 +++
cmds-fi-disk_usage.h | 3 ++
3 files changed, 142 insertions(+)
diff --git a/cmds-device.c b/cmds-device.c
index bc4a8dc..f25dbfa 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -28,6 +28,7 @@
#include ctree.h
#include ioctl.h
#include utils.h
+#include cmds-fi-disk_usage.h
#include commands.h
@@ -401,6 +402,8 @@ const struct cmd_group device_cmd_group = {
{ scan, cmd_scan_dev, cmd_scan_dev_usage, NULL, 0 },
{ ready, cmd_ready_dev, cmd_ready_dev_usage, NULL, 0 },
{ stats, cmd_dev_stats, cmd_dev_stats_usage, NULL, 0 },
+ { disk-usage, cmd_device_disk_usage,
+ cmd_device_disk_usage_usage, NULL, 0 },
NULL_CMD_STRUCT
}
};
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
index 16b3ab2..e4eb72b 100644
--- a/cmds-fi-disk_usage.c
+++ b/cmds-fi-disk_usage.c
@@ -942,3 +942,139 @@ int cmd_filesystem_disk_usage(int argc, char **argv)
return 0;
}
+
+static void print_disk_chunks(int fd,
+ u64 devid,
+ u64 total_size,
+ struct chunk_info *chunks_info_ptr,
+ int chunks_info_count,
+ int mode)
+{
+ int i;
+ u64 allocated = 0;
+
+ for (i = 0 ; i chunks_info_count ; i++) {
+ const char *description;
+ const char *r_mode;
+ u64 flags;
+ u64 size;
+
+ if (chunks_info_ptr[i].devid != devid)
+ continue;
+
+ flags = chunks_info_ptr[i].type;
+
+ description = group_type_str(flags);
+ r_mode = group_profile_str(flags);
+ size = calc_chunk_size(chunks_info_ptr+i);
+ printf( %s,%s:%*s%10s\n,
+ description,
+ r_mode,
+ (int)(20 - strlen(description) - strlen(r_mode)), ,
+ df_pretty_sizes(size, mode));
+
+ allocated += size;
+
+ }
+ printf( Unallocated: %*s%10s\n,
+ (int)(20 - strlen(Unallocated)), ,
+ df_pretty_sizes(total_size - allocated, mode));
+
+}
+
+static int _cmd_device_disk_usage(int fd, char *path, int mode)
+{
+ int i;
+ int ret = 0;
+ int info_count = 0;
+ struct chunk_info *info_ptr = 0;
+ struct disk_info *disks_info_ptr = 0;
+ int disks_info_count = 0;
+
+ if (load_chunk_info(fd, info_ptr, info_count) ||
+ load_disks_info(fd, disks_info_ptr, disks_info_count)) {
+ ret = -1;
+ goto exit;
+ }
+
+ for (i = 0 ; i disks_info_count ; i++) {
+ printf(%s\t%10s\n, disks_info_ptr[i].path,
+ df_pretty_sizes(disks_info_ptr[i].size, mode));
+
+ print_disk_chunks(fd, disks_info_ptr[i].devid,
+ disks_info_ptr[i].size,
+ info_ptr, info_count,
+ mode);
+ printf(\n);
+
+ }
+
+
+exit:
+
+ if (disks_info_ptr)
+ free(disks_info_ptr);
+ if (info_ptr)
+ free(info_ptr);
+
+ return ret;
+}
+
+const char * const cmd_device_disk_usage_usage[] = {
+ btrfs device disk-usage [-b] path [path..],
+ Show which chunks are in a device.,
+ ,
+ -b\tSet byte as unit,
+ NULL
+};
+
+int cmd_device_disk_usage(int argc, char **argv)
+{
+
+ int flags = DF_HUMAN_UNIT;
+ int i, more_than_one = 0;
+
+ optind = 1;
+ while (1) {
+ charc = getopt(argc, argv, b);
+
+ if (c 0)
+ break;
+
+ switch (c) {
+ case 'b':
+ flags = ~DF_HUMAN_UNIT;
+ break;
+ default:
+ usage(cmd_device_disk_usage_usage);
+ }
+ }
+
+ if (check_argc_min(argc - optind, 1)) {
+ usage(cmd_device_disk_usage_usage);
+ return 21;
+ }
+
+ for (i = optind; i argc ; i++) {
+ int r, fd;
+ DIR *dirstream = NULL;
+ if (more_than_one)
+ printf(\n);
+
+ fd = open_file_or_dir(argv[i], dirstream);
+ if (fd 0) {
+ fprintf(stderr, ERROR: can't access to '%s'\n,
+ argv[1]);
+ return 12;
+ }
+ r = _cmd_device_disk_usage(fd, argv[i], flags);
+ close_file_or_dir(fd, dirstream);
+
+ if (r)
+ return r
[PATCH 8/8] Create a new entry in btrfs man page for btrfs device disk-usage.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
man/btrfs.8.in | 11 +++
1 file changed, 11 insertions(+)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 4b7e771..0984504 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -59,6 +59,9 @@ btrfs \- control a btrfs filesystem
.PP
\fBbtrfs\fP \fBdevice scan\fP [\fI--all-devices\fP|\fIdevice
\P[\fIdevice...\fP]
.PP
+\fBbtrfs\fP \fBdevice disk-usage\fP\fI [-b] path [path...] \fP
+.PP
+.PP
\fBbtrfs\fP \fBdevice ready\fP\fI device\fP
.PP
\fBbtrfs\fP \fBdevice stats\fP [-z] {\fIpath\fP|\fIdevice\fP}
@@ -474,6 +477,14 @@ Remove device(s) from a filesystem identified by
\fIpath\fR.
.TP
\fBdevice scan\fR [--all-devices|\fIdevice \fP[\fIdevice...\fP]\fR
+.TP
+
+\fBdevice disk-usage\fR\fI [-b] path [path..] path\fR
+Show which chunks are in a device.
+
+\fB-b\fP set byte as unit.
+.TP
+
If one or more devices are passed, these are scanned for a btrfs filesystem.
If no devices are passed, \fBbtrfs\fR uses block devices containing btrfs
filesystem as listed by blkid.
--
1.8.5.3
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 7/8] Add btrfs device disk-usage command
Hi Roman, On 02/13/2014 08:23 PM, Roman Mamedov wrote: On Thu, 13 Feb 2014 20:20:12 +0100 Goffredo Baroncelli kreij...@libero.it wrote: Signed-off-by: Goffredo Baroncelli kreij...@inwind.it --- [...] Why not just name it du? Think about the current handy feature of shortening commands by only specifying parts of the keywords. btrfs dev du would seem more intuitive than calling it as btrfs dev disk or btrfs dev disk-u. Or simply usage, because ...device disk... is redundant, device is already a disk, so it can easily be btrfs device usage. Yes, I agree about usage GB -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 5/8] Add command btrfs filesystem disk-usage
Hi Roman
On 02/13/2014 08:28 PM, Roman Mamedov wrote:
On Thu, 13 Feb 2014 20:19:50 +0100
Goffredo Baroncelli kreij...@libero.it wrote:
[...]
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index fc85eef..d4cab63 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesystem.c
@@ -798,6 +798,9 @@ const struct cmd_group filesystem_cmd_group = {
{ balance, cmd_balance, NULL, balance_cmd_group, 1 },
{ resize, cmd_resize, cmd_resize_usage, NULL, 0 },
{ label, cmd_label, cmd_label_usage, NULL, 0 },
+{ disk-usage, cmd_filesystem_disk_usage,
+cmd_filesystem_disk_usage_usage, NULL, 0 },
+
Same here, I'd suggest du or usage.
As currently in the patch it's not shorthand-friendly, you basically propose
that people wishing a shorter invocation use it as btrfs fi di or btrfs fi
disk, which seems awkward and not intuitive.
Thanks for the comments, however I don't like du not usage; but you are right
when you don't like disk-usage. What about btrfs filesystem chunk-usage ?
The short form would be
btrfs fi chunk
which is coherent with the data displayed
Regards
Goffredo
P.S.
Please the next time, cut the email lines which are not relevant to your
replay
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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-RAID(3 or 5/6/etc) like btrfs-RAID1?
Hi Jim, On 02/13/2014 05:13 PM, Jim Salter wrote: This might be a stupid question but... There is no stupid questions, only stupid answers... Are there any plans to make parity RAID levels in btrfs similar to the current implementation of btrfs-raid1? It took me a while to realize how different and powerful btrfs-raid1 is from traditional raid1. The ability to string together virtually any combination of mutt hard drives together in arbitrary ways and yet maintain redundancy is POWERFUL, and is seriously going to be a killer feature advancing btrfs adoption in small environments. The one real drawback to btrfs-raid1 is that you're committed to n/2 storage efficiency, since you're using pure redundancy rather than parity on the array. I was thinking about that this morning, and suddenly it occurred to me that you ought to be able to create a striped parity array in much the same way as a btrfs-raid1 array. Let's say you have five disks, and you arbitrarily want to define a stripe length of four data blocks plus one parity block per stripe. I what it is different from a raid5 setup (which is supported by btrfs)? Right now, what you're looking at effectively amounts to a RAID3 array, like FreeBSD used to use. But, what if we add two more disks? Or three more disks? Or ten more? Is there any reason we can't keep our stripe length of four blocks + one parity block, and just distribute them relatively ad-hoc in the same way btrfs-raid1 distributes redundant data blocks across an ad-hoc array of disks? This could be a pretty powerful setup IMO - if you implemented something like this, you'd be able to arbitrarily define your storage efficiency (percentage of parity blocks / data blocks) and your fault-tolerance level (how many drives you can afford to lose before failure) WITHOUT tying it directly to your underlying disks May be that it is a good idea, but which would be the advantage to use less drives that the available ones for a RAID ? Regarding the fault tolerance level, few weeks ago there was a posting about a kernel library which would provide a generic RAID framework capable of several degree of fault tolerance (raid 5,6,7...) [give a look to [RFC v4 2/3] fs: btrfs: Extends btrfs/raid56 to support up to six parities 2014/1/25]. This definitely would be a big leap forward. BTW, the raid5/raid6 support in BTRFS is only for testing purpose. However Chris Mason, told few week ago that he will work on these issues. [...] necessarily needing to rebalance as you add more disks to the array. This would be a heck of a lot more flexible than ZFS' approach of adding more immutable vdevs. There is no needing to re-balance if you add more drives. The next chunk allocation will span all the available drives anyway. It is only required when you want to spans all data already written on all the drives. Regards Goffredo -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 5/8] Add command btrfs filesystem disk-usage
On 02/14/2014 07:11 PM, Roman Mamedov wrote: On Fri, 14 Feb 2014 18:57:03 +0100 Goffredo Baroncelli kreij...@libero.it wrote: On 02/13/2014 10:00 PM, Roman Mamedov wrote: On Thu, 13 Feb 2014 20:49:08 +0100 Goffredo Baroncelli kreij...@libero.it wrote: Thanks for the comments, however I don't like du not usage; but you are right when you don't like disk-usage. What about btrfs filesystem chunk-usage ? Personally I don't see the point of being super-pedantic here, i.e. look this is not just filesystem usage, this is filesystem CHUNK usage... Consistency of having a matching dev usage and fi usage would have been nicer. What about btrfs filesystem chunk-usage ? Uhm? Had to reread this several times, but it looks like you're repeating exactly the same question that I was already answering in the quoted part. To clarify even more, personally I'd like if there would have been btrfs dev usage and btrfs fi usage. Do not see the need to specifically make the 2nd one chunk-usage instead of simply usage. I don't like usage because it to me seems to be too much generic. Because both btrfs filesystem disk-usage and btrfs device disk-usage report about chunk (and/or block group) infos, I am investigating about - btrfs filesystem chunk-usage - btrfs device chunk-usage Regards GB -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 5/8] Add command btrfs filesystem disk-usage
On 02/15/2014 11:23 PM, Chris Murphy wrote:
On Feb 14, 2014, at 11:34 AM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, Feb 14, 2014 at 07:27:57PM +0100, Goffredo Baroncelli wrote:
On 02/14/2014 07:11 PM, Roman Mamedov wrote:
On Fri, 14 Feb 2014 18:57:03 +0100
Goffredo Baroncelli kreij...@libero.it wrote:
On 02/13/2014 10:00 PM, Roman Mamedov wrote:
On Thu, 13 Feb 2014 20:49:08 +0100
Goffredo Baroncelli kreij...@libero.it wrote:
Thanks for the comments, however I don't like du not usage; but you are
right
when you don't like disk-usage. What about btrfs filesystem
chunk-usage ?
Personally I don't see the point of being super-pedantic here, i.e.
look this
is not just filesystem usage, this is filesystem CHUNK usage...
Consistency
of having a matching dev usage and fi usage would have been nicer.
What about btrfs filesystem chunk-usage ?
Uhm? Had to reread this several times, but it looks like you're repeating
exactly the same question that I was already answering in the quoted part.
To clarify even more, personally I'd like if there would have been btrfs
dev
usage and btrfs fi usage. Do not see the need to specifically make the
2nd
one chunk-usage instead of simply usage.
I don't like usage because it to me seems to be too much generic.
Because both btrfs filesystem disk-usage and btrfs device disk-usage
report about chunk (and/or block group) infos, I am investigating
about
- btrfs filesystem chunk-usage
- btrfs device chunk-usage
Most people aren't going to know (or care) what a chunk is. I'm
much happier with Roman's suggestion of btrfs {fi,dev} usage.
Or btrfs filesystem examine, or btrfs filesystem detail, which are
semi-consistent with mdadm for obtaining similar data.
I have to agree with Chris: looking at the output of btrfs fi disk-usage
$ sudo ./btrfs filesystem disk-usage -t /mnt/btrfs1/
Data DataMetadata Metadata System System
Single RAID6 Single RAID5Single RAID5 Unallocated
/dev/vdb 8.00MB 1.00GB 8.00MB 1.00GB 4.00MB 4.00MB 97.98GB
/dev/vdc - 1.00GB- 1.00GB - 4.00MB 98.00GB
/dev/vdd - 1.00GB- 1.00GB - 4.00MB 98.00GB
/dev/vde - 1.00GB- 1.00GB - 4.00MB 98.00GB
== === == === ===
Total8.00MB 2.00GB 8.00MB 3.00GB 4.00MB 12.00MB391.97GB
Used 0.00 11.25MB 0.00 36.00KB 0.00 4.00KB
it is hard to tell that this can be named filesystem usage. I think that
details or examine is a better name.
Regarding btrfs device usage, it seems to me more coherent. But as
reported before consistency also matters, so now I am inclined to use
detail (or examine) also for btrfs device
Chris Murphy
Regards
Goffredo
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 1/4] Btrfs-progs: new helper to parse string to u64 for btrfs
Hi Wang,
On 02/19/2014 12:17 PM, Wang Shilong wrote:
There are many places that need parse string to u64 for btrfs commands,
in fact, we do such things *too casually*, using atoi/atol/atoll..is not
right at all, and even we don't check whether it is a valid string.
Let's do everything more gracefully, we introduce a new helper
btrfs_strtoull() which will do all the necessary checks.If we fail to
parse string to u64, we will output message and exit directly, this is
something like what usage() is doing. It is ok to not return erro to
it's caller, because this function should be called when parsing arg
(just like usage!)
Please don't do that !
The error reporting of btrfs_strtoull is insufficient.
In case of invalid value the user is not able to
understand what is the the wrong parameter. This because the error
reporting is handled by the function itself. We should improve the error
messages, not hide them.
From my point of view, you have only two choices:
1) change the api as
u64 btrfs_strtoull(char *str, int *error)
or
int btrfs_strtoull(char *str, u64 *value)
and let the function to return the error code in case of parsing error.
The caller has the responsibility to inform the user of the error.
2) change the api as
u64 btrfs_strtoull(char *str, char *parameter_name)
so the function in case of error, is able to tell which parameters is wrong.
I prefer the #1.
BR
G.Baroncelli
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
utils.c | 19 +++
utils.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/utils.c b/utils.c
index 97e23d5..0698d8d 100644
--- a/utils.c
+++ b/utils.c
@@ -1520,6 +1520,25 @@ scan_again:
return 0;
}
+u64 btrfs_strtoull(char *str, int base)
+{
+ u64 value;
+ char *ptr_parse_end = NULL;
+ char *ptr_str_end = str + strlen(str);
+
+ value = strtoull(str, ptr_parse_end, base);
+ if (ptr_parse_end != ptr_str_end) {
+ fprintf(stderr, ERROR: %s is not an invalid unsigned long long
integer.\n,
+ str);
+ exit(1);
+ }
+ if (value == ULONG_MAX) {
+ fprintf(stderr, ERROR: %s is out of range.\n, str);
+ exit(1);
+ }
+ return value;
+}
+
u64 parse_size(char *s)
{
int i;
diff --git a/utils.h b/utils.h
index 04b8c45..094f41d 100644
--- a/utils.h
+++ b/utils.h
@@ -71,6 +71,7 @@ int pretty_size_snprintf(u64 size, char *str, size_t
str_bytes);
int get_mountpt(char *dev, char *mntpt, size_t size);
int btrfs_scan_block_devices(int run_ioctl);
u64 parse_size(char *s);
+u64 btrfs_strtoull(char *str, int base);
int open_file_or_dir(const char *fname, DIR **dirstream);
void close_file_or_dir(int fd, DIR *dirstream);
int get_fs_info(char *path, struct btrfs_ioctl_fs_info_args *fi_args,
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 1/4] Btrfs-progs: new helper to parse string to u64 for btrfs
Hi Wang,
On 02/19/2014 05:08 PM, Wang Shilong wrote:
Hi Goffredo,
Hi Wang,
On 02/19/2014 12:17 PM, Wang Shilong wrote:
There are many places that need parse string to u64 for btrfs commands,
in fact, we do such things *too casually*, using atoi/atol/atoll..is not
right at all, and even we don't check whether it is a valid string.
Let's do everything more gracefully, we introduce a new helper
btrfs_strtoull() which will do all the necessary checks.If we fail to
parse string to u64, we will output message and exit directly, this is
something like what usage() is doing. It is ok to not return erro to
it's caller, because this function should be called when parsing arg
(just like usage!)
Please don't do that !
The error reporting of btrfs_strtoull is insufficient.
In case of invalid value the user is not able to
understand what is the the wrong parameter. This because the error
reporting is handled by the function itself. We should improve the error
messages, not hide them.
From my point of view, you have only two choices:
1) change the api as
u64 btrfs_strtoull(char *str, int *error)
or
int btrfs_strtoull(char *str, u64 *value)
and let the function to return the error code in case of parsing error.
The caller has the responsibility to inform the user of the error.
2) change the api as
u64 btrfs_strtoull(char *str, char *parameter_name)
so the function in case of error, is able to tell which parameters is wrong.
I prefer the #1.
I know what you are considering here, i was thinking the way you talked about.
I chose this way for three reasons:
#1 btrfs_strtoul() itself would output message why we fail before
exit.
The error message says that the value is out of range. But doesn't tell which
is the parameter involved.
If you have a command which has several arguments, and the user pass a string
instead of a number, the error returned doesn't tell which argument is wrong.
This is the reason of my complaint.
At least add a fourth parameter which contains the name of the parameter
parsed in order to improve the error message.
I.E.
subvol_id = btrfs_strtoull(argv[i], 10, subvolume ID);
If the user pass a path instead of a number the error message would be
ERROR: is not a valid unsigned long long integer for the parameter
'subvolume ID'.
Or something like that.
#2 btrfs_strtoull() is called when arg parsing just like we use
the function usage() which will call exit(1).
Yes this could be a reasonable tread off, even I would prefer a more
explicit name of the function (like argv_strtoull) in order to highlight
that it is a special function which could exit.
#3 if we return error
message to the caller, just think there are many caller that will
deal the same thing, check and output error messages….which is a
little polluted information….
So i think it is ok that we output message in btrfs_strtoull() itself
and return directly.(It is ok because during arg parsing we don't
involve memory allocation etc…)
I understand your suggestions is more common, but for this case, I
am more inclined to the current way to deal with the issue.^_^
Thanks,
Wang
BR
G.Baroncelli
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
utils.c | 19 +++
utils.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/utils.c b/utils.c
index 97e23d5..0698d8d 100644
--- a/utils.c
+++ b/utils.c
@@ -1520,6 +1520,25 @@ scan_again:
return 0;
}
+u64 btrfs_strtoull(char *str, int base)
+{
+ u64 value;
+ char *ptr_parse_end = NULL;
+ char *ptr_str_end = str + strlen(str);
+
+ value = strtoull(str, ptr_parse_end, base);
+ if (ptr_parse_end != ptr_str_end) {
+ fprintf(stderr, ERROR: %s is not an invalid unsigned long long
integer.\n,
+ str);
+ exit(1);
+ }
+ if (value == ULONG_MAX) {
+ fprintf(stderr, ERROR: %s is out of range.\n, str);
+ exit(1);
+ }
+ return value;
+}
+
u64 parse_size(char *s)
{
int i;
diff --git a/utils.h b/utils.h
index 04b8c45..094f41d 100644
--- a/utils.h
+++ b/utils.h
@@ -71,6 +71,7 @@ int pretty_size_snprintf(u64 size, char *str, size_t
str_bytes);
int get_mountpt(char *dev, char *mntpt, size_t size);
int btrfs_scan_block_devices(int run_ioctl);
u64 parse_size(char *s);
+u64 btrfs_strtoull(char *str, int base);
int open_file_or_dir(const char *fname, DIR **dirstream);
void close_file_or_dir(int fd, DIR *dirstream);
int get_fs_info(char *path, struct btrfs_ioctl_fs_info_args *fi_args,
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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
--
gpg @keyserver.linux.it
Re: [PATCH][BTRFS-PROGS][v4] Enhance btrfs fi df
Hi David, below my comments On 02/20/2014 07:08 PM, David Sterba wrote: On Thu, Feb 13, 2014 at 08:18:10PM +0100, Goffredo Baroncelli wrote: space (if the next chunk are allocated as SINGLE) or the minimum one ( if the next chunks are allocated as DUP/RAID1/RAID10). The other two commands show the chunks in the disks. $ sudo btrfs filesystem disk-usage /mnt/btrfs1/ Data,Single: Size:8.00MB, Used:0.00 /dev/vdb 8.00MB The information about per-device usage can be enhanced and there's enough space to print that: * allocated in chunks (the number above) This is the value already written. * actually used (simiar to what 'btrfs fi show' prints as 'used') The used is a value returned by the ioctl BTRFS_IOC_SPACE_INFO, which returns this value per group-block basis. See below. I don't see a reason why it would not fit here, nor any other place where this can be obtained. There is the cumulative number of 'Used' for all devices, but I'd like to see it per-device as well. or in tabular format $ sudo ./btrfs filesystem disk-usage -t /mnt/btrfs1/ Data DataMetadata Metadata System System Single RAID6 Single RAID5Single RAID5 Unallocated /dev/vdb 8.00MB 1.00GB 8.00MB 1.00GB 4.00MB 4.00MB 97.98GB /dev/vdc - 1.00GB- 1.00GB - 4.00MB 98.00GB /dev/vdd - 1.00GB- 1.00GB - 4.00MB 98.00GB /dev/vde - 1.00GB- 1.00GB - 4.00MB 98.00GB == === == === === Total8.00MB 2.00GB 8.00MB 3.00GB 4.00MB 12.00MB391.97GB Used 0.00 11.25MB 0.00 36.00KB 0.00 4.00KB These are the most complete output, where it is possible to know which disk a chunk uses and the usage of every chunk. Though not per-device, similar to the above, but the tabular output is limited compared to the sequential output. Not sure what to do here. The tabular is to have a friendly summary of how the filesystem is span on the different disks. I suggest to not add more info in the tabular Finally the last command shows which chunks a disk hosts: $ sudo ./btrfs device disk-usage /mnt/btrfs1/ /dev/vdb 100.00GB Data,Single: 8.00MB Data,RAID6: 1.00GB Metadata,Single: 8.00MB Metadata,RAID5: 1.00GB System,Single:4.00MB System,RAID5: 4.00MB Unallocated: 97.98GB /dev/vdc 100.00GB Data,RAID6: 1.00GB Metadata,RAID5: 1.00GB System,RAID5: 4.00MB Unallocated: 98.00GB /dev/vdd 100.00GB Data,RAID6: 1.00GB Metadata,RAID5: 1.00GB System,RAID5: 4.00MB Unallocated: 98.00GB /dev/vde 100.00GB Data,RAID6: 1.00GB Metadata,RAID5: 1.00GB System,RAID5: 4.00MB Unallocated: 98.00GB More or less are the same information above, only grouped by disk. Ie. it's only a variant of the 'filesystem usage' where it is grouped by blockgroup type. Why doesn't 'btrfs device usage' take a device instead of the whole filesystem? This seems counterintuitive. It should be possible to ask for a device by it or path. If a device is passed, what you would expect as output: the list of all the devices involved,or only the one(s) passed ? In other terms, the device passed has to act also as filter, or it is only a different way to indicate the path ? Also, I'd like to see all useful information about the device: * id, path, uuid, ... whatever ok, we can add a -v switch to add these further information * physical device size ok, it is already written * size visible by the filesystem Could you be more explicit ? a) For each chunk (in each disk) or b) for each disk ? And how this information per disk basis would be useful ? Example (supposing 4 disks) a) /dev/vde 100.00GB Data,RAID6: Disk size: 1.00GB, FS size: 512.00MB Metadata,RAID5: Disk size: 1.00GB, FS size: 750.00MB System,RAID5: Disk size: 4.00MB, FS size; 3.00MB Unallocated: Disk size: 98.00GB b) /dev/vde Disk size: 100.00GB, FS size: 1.28GB Data,RAID6: 1.00GB Metadata,RAID5: 1.00GB System,RAID5: 4.00MB Unallocated: 98.00GB * space allocated in chunks ok, it is already written * space actually used See my other comments I am not against to add further information to btrfs dev [disk-]usage, but I liked the idea to add the minimum information to avoid ambiguities: - the number on the left of the device is the device size - the number on the left of the block group is the space allocated on the disk
Re: [PATCH][BTRFS-PROGS][v4] Enhance btrfs fi df
Hi Josef, On 02/20/2014 07:32 PM, Josef Bacik wrote: Yes for 3), we may also export the information through the existing ioctls if possible (eg. IOC_FS_INFO). For _right now_ I'd say just not do the raid56 stuff if we don't notice any raid56 chunks from the normal load_space_info, and then if there are raid56 we try and run the tree search ioctl and notice if we get back EPERM or whatever you get when you don't have permissions. Then just spit out as much information that you can about the fs with a little note at the bottom that available calculation isn't 100% and you need to run as root if you want that info. Then what we could do is add another flag type for the existing SPACE_INFO ioctl to spit out the information you need about the raid5/6 chunks and then just test for those flags and make the adjustment necessary. This way we avoid adding yet another ioctl and stuff will still work nicely for old kernels that don't have the updated ioctl. Thanks, Josef Good suggestion ! I will take it -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/07/2014 07:26 PM, Lennart Poettering wrote: Heya! Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making /etc/fstab unnecessary for simple setups. I have now put together something like a spec describing the logic behind that, and what it is good for: http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ Form the FAQ: CITE [...] What about automatic mounting of btrfs subvolumes to /var, /home and so on? Doing a similar automatic discovery of btrfs subvolumes and mounting them automatically to the appropriate places is certainly desirable. We are waiting for the btrfs designers to add a per-subvolume type UUID to their disk format to make this possible. [...] /CITE Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them. For example supposing to use '@' as prefix for a subvolume name: @ - root filesystem @etc- etc @home - home [...] If you want multiple OS on the same filesystem we can use the following convention @home - home of all the systems @srv- srv of all the systems @fedora_- root of a fedora system @fedora_etc - etc of the fedora system @fedora2_ - root of a fedora2 system @fedora2_etc- etc of the fedora2 system Or in another way we could group the different systems in subdirectories: @home - home of all the systems @srv- srv of all the systems fedora/@- root of a fedora system fedora/@etc - etc of the fedora system fedora2/@ - root of a fedora2 system fedora2/@etc- etc of the fedora2 system -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
Hi Kay On 03/10/2014 07:53 PM, Kay Sievers wrote: [...] Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them. As a general rule: human-readable names should be left to the administrator, provide an identifier for humans, and should not be overloaded with magic machine behavior. In general I agree with you. But using a name you can manage multiple system on the same filesystem. This is impossible with the UUID. KayGoffredo-- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/10/2014 09:02 PM, Lennart Poettering wrote: On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote: Heya, Instead of relying on the subvolume UUID, why not relying to the subvolume name: it would be more simple and flexible to manage them. For example supposing to use '@' as prefix for a subvolume name: @- root filesystem @etc - etc @home- home [...] Well, the name is property of the admin really. There needs to be a way how the admin can label his subvolumes, with a potentially localized name. This makes it unsuitable for our purpose, we cannot just take possession of this and leave the admin with nothing. Instead of the name we can use the xattr to store these information. On GPT there are also gpt partition labels and partition types. The former are property of the admin, he can place there whatever he wants, in whatever language he chooses... The latter however is how we make sense of it on a semantical level. Or in another way we could group the different systems in subdirectories: @home- home of all the systems @srv - srv of all the systems fedora/@ - root of a fedora system fedora/@etc - etc of the fedora system fedora2/@- root of a fedora2 system fedora2/@etc - etc of the fedora2 system I am pretty sure automatic discovery of mount points should not cover the usecase where people install multiple distributions into the same btrfs volume. THe automatic logic should cover the simple cases only, and it sounds way over the top to support installing multiple OSes into the same btrfs... I mean, people can do that, if they want to, they just have to write a proper fstab, which I think is not too much too ask... In your specification, you referred the use case of container (via nspawn / libvrt-lxc). which have to boot a disk image. Why you don't mind to use a container on a btrfs snapshot ? I think that it will be reasonable to have different containers on a snapshots of the same filesystem-tree. Lennart -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/10/2014 09:21 PM, Chris Mason wrote: On 03/10/2014 04:02 PM, Lennart Poettering wrote: On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote: [...] I am pretty sure automatic discovery of mount points should not cover the usecase where people install multiple distributions into the same btrfs volume. THe automatic logic should cover the simple cases only, and it sounds way over the top to support installing multiple OSes into the same btrfs... I mean, people can do that, if they want to, they just have to write a proper fstab, which I think is not too much too ask... Thinking more about this, using the UUIDs does make it harder for the admin to roll back and forth between snapshots. This is similar to the multiple install idea, but the goal would be easily jumping back to the old one if an update failed. I'm not against anything that makes us more flexible here, just trying to nail down the use case a little bit more. We can store the mount point in a xattr. Also we can store the snapshots relation (parent/child or real/rollback) in a xattr. During the boot a systemd-btrfs-fstab-generator could generate on the fly the right mounts list. -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 -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/12/2014 06:24 PM, Chris Mason wrote: On 03/10/2014 07:45 PM, Lennart Poettering wrote: On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote: Well, the name is property of the admin really. There needs to be a way how the admin can label his subvolumes, with a potentially localized name. This makes it unsuitable for our purpose, we cannot just take possession of this and leave the admin with nothing. Instead of the name we can use the xattr to store these information. Ah, using xattrs for this is indeed an option. That way we should be able attach any kind of information we like to a subvolume. Hmm, I figure though that there is no way currently to read xattrs off a subvolume without first mounting them individually? Having to mount all subvolumes before we can make sense of them and mount them to the right place certainly sounds less than ideal... Ok, are we hoping to pull the xattrs off the disk before mounting anything? Or can we do a mount in a side directory first to scan for subvols? I like the idea of something like this: mount device on /search_for_fstab cd /search_for_fstab/some_magic_directory_name_option_in_systemd read xattrs on directories it finds to see where they should be mounted in the FS. xattrs may include mount options and special flags. I am working to prototype something like that. A mount.btrfs command which 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the original subvolume) 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place) My idea is that the subvolume are grouped so: @name simple subvolume @name.timestamp snapshot of subvolume name @name.rollbackrollback subvolume If @name.rollback exists, then it replace @name (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume) For each @name subvolume the following xattrs are considered: user.btrfs.automount=1|0the subvolume has to be automounted user.btrfs.mntpoint=path subvolume mount point So this mount.btrsf command should: 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory 2) performing the auto rollback (this behaviour can be controlled by another xattr) 3) mount the subvolume @ as root (like the default one) in the right mount point 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the user.btrfs.mntpoint xattr (relative to @ or absolute) 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order to allow managing (snapshot) of the different subvolumes. Thoughts ? BR G.Baroncelli mount the things you find umount /search_for_fstab I like that it's not actually btrfs specific, since the bind mounts will work for any FS. But it naturally fits the /@ namespace that we seem to be favoring as a collection point for snapshots and subvolumes. -chris -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/12/2014 08:31 PM, Chris Murphy wrote: On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli kreij...@inwind.it wrote: [...] I am working to prototype something like that. A mount.btrfs command which 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the original subvolume) 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place) My idea is that the subvolume are grouped so: @name simple subvolume @name.timestamp snapshot of subvolume name @name.rollback rollback subvolume If @name.rollback exists, then it replace @name (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume) For each @name subvolume the following xattrs are considered: user.btrfs.automount=1|0 the subvolume has to be automounted user.btrfs.mntpoint=path subvolume mount point So this mount.btrsf command should: 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory 2) performing the auto rollback (this behaviour can be controlled by another xattr) 3) mount the subvolume @ as root (like the default one) in the right mount point 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the user.btrfs.mntpoint xattr (relative to @ or absolute) 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order to allow managing (snapshot) of the different subvolumes. Thoughts ? In effect this obviates boot parameter rootflags=subvol= since the file system metadata self-describe the subvol to be mounted, correct? Definetely; Your suggestion also sounds like it places snapshots outside of their parent subvolume? yes, to me snapshot and parent subvolume are sibling more than parent/child. This simplify the rollback scenario. For example using the convention above we can rollback all the subvolumes mounting all the snapshots where the timestamp is less than the desired value. If so it mitigates a possible security concern if the snapshot contains (old) binaries with vulnerabilities. I asked about how to go about assessing this on the Fedora security list: https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html There aren't many replies but the consensus is that it's a legitimate concern, so either the snapshots shouldn't be persistently available (which is typical with e.g. snapper, and also yum-plugin-fs-snapshot), and/or when the subvolume containing snapshots is mounted, it's done with either mount option noexec or nosuid (no consensus on which one, although Gnome Shell uses nosuid by default when automounting removable media). Interesting observation Chris Murphy -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
On 03/12/2014 08:12 PM, Goffredo Baroncelli wrote:
[...]
I am working to prototype something like that. A mount.btrfs command which
1) handles the rollback (i.e. the user make a snapshot which is a rollback;
if something goes wrong and the machine reboot before ending the process,
during the subvolume mounting phase the rollback replaces the original
subvolume)
2) handles the automount (i.e. if a subvolume has the right xattr it is
automatically mounted in the right place)
My idea is that the subvolume are grouped so:
@name simple subvolume
@name.timestamp snapshot of subvolume name
@name.rollback rollback subvolume
If @name.rollback exists, then it replace @name (something went wrong,
the machine rebooted so the rollback have to take place of the original
subvolume)
For each @name subvolume the following xattrs are considered:
user.btrfs.automount=1|0 the subvolume has to be automounted
user.btrfs.mountpoint=path subvolume mount point
So this mount.btrfs command should:
1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
2) performing the auto rollback (this behaviour can be controlled by another
xattr)
3) mount the subvolume @ as root (like the default one) in the right
mount point
4) for each subvolume which has user.btrfs.automount=1, it should be mounted
under the path stored in the user.btrfs.mntpoint xattr (relative to @ or
absolute)
5) umount the btrfs filesystem mounted at #1, or better move it to a new
position in order
to allow managing (snapshot) of the different subvolumes.
Below my POC.
$ sudo mount /dev/loop0 t
$ sudo getfattr -d t/{@*,.}
# file: t/@
user.btrfs.automount=1
# file: t/@__boot__
user.btrfs.automount=1
user.btrfs.mountpoint=/boot
# file: t/@.broken-0
user.btrfs.automount=1
# file: t/@.broken-1
user.btrfs.automount=1
# file: t/@__home__
user.btrfs.automount=1
user.btrfs.mountpoint=/home
# file: t/@__root__.12345
user.btrfs.automount=0
# file: t/@space space
user.btrfs.automount=0
# file: t/@__srv__
user.btrfs.automount=0
# file: t/.
user.btrfs.automount=1
user.btrfs.autorollback=1
user.btrfs.mountpoint=/var/btrfs
$ sudo umount t
$ sudo sh mount.btrfs /dev/loop0 t
Mount /dev/loop0/@ - t
Mount /dev/loop0/@__boot__ - t//boot
Mount /dev/loop0/@__home__ - t//home
Mount /dev/loop0 - t//var/btrfs
ghigo@venice:~/btrfs/mount-btrfs$ find t
t
t/var
t/var/btrfs
t/var/btrfs/@__boot__
t/var/btrfs/@__home__
t/var/btrfs/@__srv__
t/var/btrfs/@__root__.12345
t/var/btrfs/@space space
t/var/btrfs/@.broken-0
t/var/btrfs/@.broken-0/var
t/var/btrfs/@.broken-0/var/btrfs
t/var/btrfs/@.broken-0/@__boot__
t/var/btrfs/@.broken-0/@__home__
t/var/btrfs/@.broken-0/boot
t/var/btrfs/@.broken-0/home
t/var/btrfs/@.broken-0/non-rollback-subvol
t/var/btrfs/@.broken-1
t/var/btrfs/@.broken-1/var
t/var/btrfs/@.broken-1/var/btrfs
t/var/btrfs/@.broken-1/@__boot__
t/var/btrfs/@.broken-1/@__home__
t/var/btrfs/@.broken-1/boot
t/var/btrfs/@.broken-1/home
t/var/btrfs/@.broken-1/rollback-subvol
find: File system loop detected; ‘t/var/btrfs/@’ is part of the same file
system loop as ‘t’.
t/@__boot__
t/@__home__
t/boot
t/home
t/non-rollback-subvol
$cat mount.btrfs
#!/bin/sh
XAAMOUNT=user.btrfs.automount
XAAMNTPNT=user.btrfs.mountpoint
XAAROLLBACK=user.btrfs.autorollback
xdebug() {
[ -z $DEBUG ] return
echo $@
}
autorollback() {
( cd $tmpdir; ls -d @*.rollback 2/dev/null) | while read drb; do
rbfullpath=$tmpdir/$drb
[ ! -d $rbfullpath ] continue
is_btrfs_subvol $rbfullpath || continue
f=$(get_fattr $XAAROLLBACK $rbfullpath )
[ x$f = x0 ] continue
d=$(echo $drb | sed -e s/.rollback$//)
fullpath=$tmpdir/$d
if [ -d $fullpath ]; then
f=$(get_fattr $XAAROLLBACK $fullpath )
[ x$f = x0 ] continue
i=0
while true; do
newfullpath=$fullpath.broken-$i
if [ ! -e $newfullpath ]; then
mv $fullpath $newfullpath
break
fi
i=$(($i+1))
done
fi
echo Rollback $d
mv $rbfullpath $fullpath
done
}
is_btrfs_subvol() {
[ $(stat -c %i $1) -eq 256 ]
}
get_fattr() {
name=$1
file=$2
getfattr --only-values -n $name $file 2/dev/null || echo -n
}
automount() {
tmpdir=$1
srcdev=$2
mntpnt=$3
fullpath=$tmpdir/@
[ ! -d $fullpath ] return 1
is_btrfs_subvol $fullpath || return 1
b=$(get_fattr $XAAMOUNT $fullpath )
[ x$b = x0 ] return 1
path=$(get_fattr $XAAMNTPNT $fullpath )
if [ -n $path ] ; then
mntpnt=$path
fi
xdebug mount -o subvol=@ $srcdev $mntpnt/
echo Mount $srcdev/@ - $mntpnt
mount -o subvol=@ $srcdev $mntpnt/ || return 1
( cd $tmpdir; ls -d @* 2/dev/null) | grep -v
Re: [PATCH 07/14] btrfs-progs: Print more info about device sizes
I David
thanks, to take care of these enhancements.
On 04/29/2014 09:23 PM, Mike Fleetwood wrote:
On 29 April 2014 17:02, David Sterba dste...@suse.cz wrote:
The entire device size may not be available to the filesystem, eg. if
it's modified via resize. Print this information if it can be obtained
from the DEV_INFO ioctl.
Print the device ID on the same line as the device name and move size to
the next line.
Sample:
/dev/sda7, ID: 3
Device size:10.00GiB
FS occuppied:5.00GiB
Spelling mistake. s/occuppied/occupied/.
I found a bit unclear the FS occupied terms.
Can I suggest Resized to: instead of FS occupied:, and to show it only when
the two values differ ? In fact this value has a meaning only if a filesystem
is resized.
BR
G.Baroncelli
Data,RAID10: 512.00MiB
Metadata,RAID10: 512.00MiB
System,RAID10: 4.00MiB
Unallocated: 9.00GiB
Signed-off-by: David Sterba dste...@suse.cz
---
cmds-device.c| 6 +++---
cmds-fi-disk_usage.c | 13 -
cmds-fi-disk_usage.h | 6 +-
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
index 7a9d808b36dd..519725f83e8c 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -447,9 +447,9 @@ static int _cmd_device_usage(int fd, char *path, int
mode)
}
for (i = 0; i device_info_count; i++) {
- printf(%s\t%10s\n, device_info_ptr[i].path,
- df_pretty_sizes(device_info_ptr[i].size, mode));
-
+ printf(%s, ID: %llu\n, device_info_ptr[i].path,
+ device_info_ptr[i].devid);
+ print_device_sizes(fd, device_info_ptr[i], mode);
print_device_chunks(fd, device_info_ptr[i].devid,
device_info_ptr[i].size,
info_ptr, info_count,
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
index 067c60078710..ddb064cc4c66 100644
--- a/cmds-fi-disk_usage.c
+++ b/cmds-fi-disk_usage.c
@@ -499,7 +499,8 @@ int load_device_info(int fd, struct device_info
**device_info_ptr,
info[ndevs].devid = dev_info.devid;
strcpy(info[ndevs].path, (char *)dev_info.path);
- info[ndevs].size = get_partition_size((char *)dev_info.path);
+ info[ndevs].device_size = get_partition_size((char
*)dev_info.path);
+ info[ndevs].size = dev_info.total_size;
++ndevs;
}
@@ -879,5 +880,15 @@ void print_device_chunks(int fd, u64 devid, u64
total_size,
printf( Unallocated: %*s%10s\n,
(int)(20 - strlen(Unallocated)), ,
df_pretty_sizes(total_size - allocated, mode));
+}
+void print_device_sizes(int fd, struct device_info *devinfo, int mode)
+{
+ printf( Device size: %*s%10s\n,
+ (int)(20 - strlen(Device size)), ,
+ df_pretty_sizes(devinfo-device_size, mode));
+ printf( FS occuppied:%*s%10s\n,
Here too. s/occuppied/occupied/.
+ (int)(20 - strlen(FS occupied)), ,
+ df_pretty_sizes(devinfo-size, mode));
+ }
}
diff --git a/cmds-fi-disk_usage.h b/cmds-fi-disk_usage.h
index 787b4eb56acf..79cc2a115bc5 100644
--- a/cmds-fi-disk_usage.h
+++ b/cmds-fi-disk_usage.h
@@ -27,7 +27,10 @@ int cmd_filesystem_usage(int argc, char **argv);
struct device_info {
u64 devid;
charpath[BTRFS_DEVICE_PATH_NAME_MAX];
- u64 size;
+ /* Size of the block device */
+ u64 device_size;
+ /* Size that's occupied by the filesystem, can be changed via resize
*/
+ u64 size;
};
/*
@@ -50,5 +53,6 @@ char *df_pretty_sizes(u64 size, int mode);
void print_device_chunks(int fd, u64 devid, u64 total_size,
struct chunk_info *chunks_info_ptr,
int chunks_info_count, int mode);
+void print_device_sizes(int fd, struct device_info *devinfo, int mode);
#endif
--
1.9.0
Same spelling mistake (occuppied) also occurs in the following patches too:
[PATCH 08/14] btrfs-progs: compare unallocated space against the correct
value
[PATCH 12/14] btrfs-progs: replace df_pretty_sizes with pretty_size_mode
Thanks,
Mike
--
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
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 07/14] btrfs-progs: Print more info about device sizes
On 04/30/2014 03:37 PM, David Taylor wrote: On Wed, 30 Apr 2014, Frank Kingswood wrote: On 30/04/14 13:11, David Sterba wrote: On Wed, Apr 30, 2014 at 01:39:27PM +0200, Goffredo Baroncelli wrote: I found a bit unclear the FS occupied terms. We're running out of terms to describe and distinguish the space that the filesystem uses. 'occupied' seemed like a good choice to me, though it may be not obvious The space that the filesystem uses in total seems to me is called the size. It has nothing to do with utilization. /dev/sda6, ID: 2 Device size:10.00GiB Filesystem size: 5.00GiB FS size was what I was about to suggest, before I saw your reply. Pay attention that this value is not the Filesystem size, but to the maximum space the of THE DEVICE the filesystem is allowed to use. The filesystem size (the space available or the sum of the space available and the one occupied) is based on this value but it should be very different (think about a RAID 1 on three device of different sizes) It makes more sense to me than 'Occupied' and seems cleaner than 'Resized To'. It sort of mirrors how LVM describes PV / VG / LV sizes, too. -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 PATCH 0/2] Kernel space btrfs missing device detection.
Hi, instead of extending the BTRFS_IOCTL_DEV_INFO ioctl, why do not add a field under /sys/fs/btrfs/UUID/ ? Something like /sys/fs/btrfs/UUID/missing_device BR G.Baroncelli On 05/06/2014 08:33 AM, Qu Wenruo wrote: Original btrfs will not detection any missing device since there is no notification mechanism for fs layer to detect missing device in block layer. However we don't really need to notify fs layer upon dev remove, probing in dev_info/rm_dev ioctl is good enough since they are the only two ioctls caring about missing device. This patchset will do ioctl time missing dev detection and return device missing status in dev_info ioctl using a new member in btrfs_ioctl_dev_info_args with a backward compatible method. Cc: Anand Jain anand.j...@oracle.com Qu Wenruo (2): btrfs: Add missing device check in dev_info/rm_dev ioctl btrfs: Add new member of btrfs_ioctl_dev_info_args. fs/btrfs/ioctl.c | 4 fs/btrfs/volumes.c | 25 - fs/btrfs/volumes.h | 2 ++ include/uapi/linux/btrfs.h | 5 - 4 files changed, 34 insertions(+), 2 deletions(-) -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: Thoughts on RAID nomenclature
On 05/05/2014 11:17 PM, Hugo Mills wrote:
[...]
Does this all make sense? Are there any other options or features
that we might consider for chunk allocation at this point?
The kind of chunk (DATA, METADATA, MIXED) and the subvolume (when /if this
possibility will come)
As how write this information I suggest the following options:
-[DATA|METADATA|MIXED|SYSTEM:]NcMsPp[:driveslist[:/subvolume/path]]
Where drivelist is an expression of the disks policy allocation:
a)
{sdX1:W1,sdX2:W2...}
where sdX is the partition involved and W is the weight:
#1 {sda:1,sdb:1,sdc:1} means spread all the disks
#2 {sda:1,sdb:2,sdc:3} means linear from sda to sdc
#3 {sda:1,sdb:1,sdc:2} means spread on sda and sdb (grouped)
then (when full) sdc
or
b)
#1 (sda,sdb,sdc) means spread all the disks
#2 [sda,sdb,sdc] means linear from sda to sdc
#3 [(sda,sdb),sdc] means spread on sda and sdb (grouped)
then (when full) sdc
or
c)
#1 (sda,sdb,sdc) means spread all the disks
#2 sda,sdb,sdc means linear from sda to sdc
#3 (sda,sdb),sdc means spread on sda and sdb (grouped)
then (when full) sdc
Some examples:
- 1c2s3b
Default allocation policy
- DATA:2c3s4b
Default allocation policy for the DATA
- METADATA:1c4s:(sda,sdb,sdc,sdd)
Spread over all the 4 disks for metadata
- MIXED:1c4s:sda,sdc,sdb,sdd
Linear over the 4 disks, ordered as the list for
Data+Metadata
- DATA:1c4s:(sda,sdc),(sdb,sdd)
spread over sda,sdc and then when these are
filled, spread over sdb and sdc
- METADATA:1c4s:(sda,sdb,sdc,sdd):/subvolume/path
Spread over all the 4 disks for metadata belonging the
subvolume /subvolume/path
I think it would be interesting to explore some configuration like
- DATA:1c:(sda)
- METADATA:2c:(sdb)
if sda is bigger and sdb is faster
Some further thoughts:
- more I think about the allocation policy per subvolume and/or file basis and
more I think that it would be a messy to manage
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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: How does Suse do live filesystem revert with btrfs?
On 05/07/2014 01:39 PM, Marc MERLIN wrote: On Wed, May 07, 2014 at 11:35:52AM +, Duncan wrote: Marc MERLIN posted on Wed, 07 May 2014 01:56:12 -0700 as excerpted: On Tue, May 06, 2014 at 04:26:48PM +, Duncan wrote: Marc MERLIN posted on Sun, 04 May 2014 22:04:59 -0700 as excerpted: Aaah, right, you can use a script to see the file differences between two snapshots, and then restore that with reflink if you can truly get a list of all changed files. However, that is indeed not atomic at all, even if faster than rsync. Would send/receive help in such a script? Not really, you still end up with a new snapshot that you can't live switch to. It's really either 1) reboot 2) use cp --reflink to copy a list of changed files (as well as rm to delete the ones that were removed). What I meant was... use send/receive locally, in place of the cp --reflink. This won't work since it can only work on another read-only subvolume. But you could use btrfs send -p to get a list of changes between 2 snapshots, decode that (without btrfs receive) just to spit out the names of the files that changed or got deleted. It would be wasteful since it would cause all the changed blocks to be read on the source, but still better than nothing. Really, we'd just need a btrfs --send --dry-run -v -p vol1 vol2 which would spit out a list of the file ops it would do. That'd be enough to simply grep out the deletes, do them locally and then use cp --reflink on everything else. What happens to the already opened files ? I suppose that a process which has already opened a file, see the old one; instead a new open could see the new one. If this is acceptable, why not doing mount --bind /snapshot /, or use pivot_root(2), or a overlay filesystem ? May be that we need to move also the other already mounted_filesystem (like /proc, /sys)... Marc -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: Fwd: [suggestion] Add verbose notification about inode-cache rebuild to kernel log
On 05/09/2014 04:51 PM, David Sterba wrote: On Thu, May 08, 2014 at 04:22:13PM +0200, Tomáš Pružina wrote: I ran into some troubles with inode-cache rebuilding on root fs after filesystem was mounted without inode_cache, which stalls boot of my box by several minutes. I boot from commandline like: root=/dev/sda4 rootfstype=btrfs rootflags=inode_cache,space_cache,autodefrag rw ... However when I manually remount root fs without inode_cache (for example via kexec), it triggers cache rebuild at next mount which takes several tens of minutes and mimick 'freeze' on boot. Would it be possible to put some printk saying that this is happening so users don't get confused about it?? Adding the printk is probably a good thing, but I'd rather reconsider using inode_cache at all. IMO it's supposed to fix problems with inode numbers that we don't have. IIRC, the problem is for the 32 bit system, were the API wants the inode number to be 32 bit.. In the past the inode_cache was introduced because the inode often reached 2^32 [1] Because most modern hardware is 64 bit (with the exception of ARM ?), could be make sense to allow btrfs to work without inode_cache only on 64bit, loosing the possibility to be used on 32 bit system. Instead when the inode_cache is used, btrfs still be compatible with both 32bit and 64bit systems. How often a filesystem is moved between a 64bit and 32bit systems ? [1] http://article.gmane.org/gmane.comp.file-systems.btrfs/9573 -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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: Fwd: [suggestion] Add verbose notification about inode-cache rebuild to kernel log
Hi David, On 05/12/2014 04:39 PM, David Sterba wrote: Because most modern hardware is 64 bit (with the exception of ARM ?), could be make sense to allow btrfs to work without inode_cache only on 64bit, loosing the possibility to be used on 32 bit system. Instead when the inode_cache is used, btrfs still be compatible with both 32bit and 64bit systems. There are 32bit machines in use and inode_cache brings some compatibility assurance. Just that I would not recommend it to use by default. How often a filesystem is moved between a 64bit and 32bit systems ? Not so often I'd say, but for example the block device on a 32bit machine can be exported via iscsi to a 64bit machine temporarily, then the changes made on the 64bit host can make it unusable. To be clear, I would like to avoid inode_cache on 64bit machine. In order to avoid the risk to exhaust the inode on 32bit and to be backward compatible with what already exists, we could add a flag to mkfs.btrfs to be only 64bit compatible and avoid inode_cache. It it would be faster, I am sure that there are uses cases for that. The major drawback that I see, is that it would be a code path less tested: I think that the 32bit system[*] would disappear soon Finally I have a question: it is possible to disable inode_cache ? what means the flag noinode_cache ? It means disable the inode cache at all, or only avoid to store on disk the inode cache ? [*] I means 32bit system were it is reasonable that btrfs would run. BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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] mkfs.btrfs: allow UUID specification at mkfs time
Hi Eric, On 05/14/2014 03:18 AM, Eric Sandeen wrote: Allow the specification of the filesystem UUID at mkfs time. I suggest to add some warning when this options is used, because the behavior could be very different than the one expected. I suspect that BTRFS tracks the filesystem by UUID and not by devices. When two filesystems have the same UUID at the same time, it may mount the wrong one. $ # $ # Make two *different* filesystems with the *same* UUID $ # $ UUID=e285c9bd-ea97-40b3-ad7d-8713dcfd5eea $ sudo ./mkfs.btrfs -f -U $UUID /dev/vdg $ sudo ./mkfs.btrfs -f -U $UUID /dev/vdh $ # $ # from the beginning btrfs fi show reports wrong information $ # $ sudo btrfs fi show Label: none uuid: e285c9bd-ea97-40b3-ad7d-8713dcfd5eea Total devices 1 FS bytes used 96.00KB devid1 size 50.00GB used 4.00MB path /dev/vdh devid1 size 50.00GB used 2.04GB path /dev/vdg $ # $ # mount the first one, create a new file then un-mount it $ # $ sudo mount /dev/vdg /mnt/btrfs1 $ sudo touch /mnt/btrfs1/dev-vdg $ sudo umount /dev/vdg $ # $ # mount the second one, it should be empty $ # instead btrfs mount the first one $ # $ sudo mount /dev/vdh /mnt/btrfs2 $ ls -l /mnt/btrfs2 total 0 -rw-r--r-- 1 root root 0 May 14 16:12 dev-vdg I am not against this option; I am suggesting to add a explicit warning to the user about the risk of doing that, both on the man pages and into the program. The warning should say that this option is only for testing. Better ask for a confirmation (even with an undocumented switch like '--I-know-that-I-am-doing-something-really-dangerous'). For the record, BTRFS seems unable to mount at the same time two different filesystems with the same UUID: $ # $ # try to mount two fs with the same UUID, but BTRFS doesn't allow it $ # $ sudo mount /dev/vdh /mnt/btrfs2 $ sudo mount /dev/vdg /mnt/btrfs1 ERROR: mount failed : 16 - Device or resource busy BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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] mkfs.btrfs: allow UUID specification at mkfs time
On 05/14/2014 04:41 PM, Eric Sandeen wrote: I am not against this option; I am suggesting to add a explicit warning to the user about the risk of doing that, both on the man pages and into the program. The warning should say that this option is only for testing. Better ask for a confirmation (even with an undocumented switch like '--I-know-that-I-am-doing-something-really-dangerous'). meh. ext4 and xfs have had the ability to either set or change the UUID for years, and I've not heard of any horror stories. BTRFS tracks the filesystem by UUID, so it behaves strange when two FS have the same UUID. This is the reason for adding further warning. If it would behave like ext4/xfs I didn't suggested to add any warning. For the record, BTRFS seems unable to mount at the same time two different filesystems with the same UUID: $ # $ # try to mount two fs with the same UUID, but BTRFS doesn't allow it $ # $ sudo mount /dev/vdh /mnt/btrfs2 $ sudo mount /dev/vdg /mnt/btrfs1 ERROR: mount failed : 16 - Device or resource busy (presumably the kernel said something, too?) I see nothing. Maybe it thinks that these are two disks of a multivolume-filesystem... and this seems to make it even more safe. -Eric BR G.Baroncelli -- 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 -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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 V2] mkfs.btrfs: allow UUID specification at mkfs time
On 05/14/2014 06:01 PM, David Sterba wrote:
On Wed, May 14, 2014 at 10:35:05AM -0500, Eric Sandeen wrote:
@@ -125,7 +154,19 @@ int make_btrfs(int fd, const char *device, const char
*label,
memset(super, 0, sizeof(super));
num_bytes = (num_bytes / sectorsize) * sectorsize;
- uuid_generate(super.fsid);
+ if (fs_uuid) {
+ if (uuid_parse(fs_uuid, super.fsid) != 0) {
+ fprintf(stderr, could not parse UUID: %s\n, fs_uuid);
+ ret = -EINVAL;
+ goto out;
I think the uuid validity check comes too late, IMHO it should be done
after the while/getopt block outside of make_btrfs. At this point eg.
the discard or device zeroing is already done.
Pay attention that, if you don't change the test_uuid_unique() you need to
perform the check after zeroing the disk, or otherwise you are not able to mkfs
the same disk with the same UUID (I suspect that this is a real use case for
testing).
I am still convinced that a Warning is a better way to handle these kind of
situations.
As reported before, forcing a unique UUID to be not unique is a thing to
skilled person. The problem is that BTRFS in this regard behaves differently
respect other file-systems, and even a skilled person could not be aware of the
possible problem.
In this case is better to provide a complete information, instead of
complicating the things adding further check.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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 V3] mkfs.btrfs: allow UUID specification at mkfs time
..cfac0d4 100644
--- a/utils.c
+++ b/utils.c
@@ -93,12 +93,41 @@ static u64 reference_root_table[] = {
[6] = BTRFS_CSUM_TREE_OBJECTID,
};
-int make_btrfs(int fd, const char *device, const char *label,
+int test_uuid_unique(char *fs_uuid)
+{
+ int unique = 1;
+ blkid_dev_iterate iter = NULL;
+ blkid_dev dev = NULL;
+ blkid_cache cache = NULL;
+
+ if (blkid_get_cache(cache, 0) 0) {
+ printf(ERROR: lblkid cache get failed\n);
+ return 1;
+ }
+ blkid_probe_all(cache);
+ iter = blkid_dev_iterate_begin(cache);
+ blkid_dev_set_search(iter, UUID, fs_uuid);
+
+ while (blkid_dev_next(iter, dev) == 0) {
This function should skip the check for the devices involved in the mkfs.
+ dev = blkid_verify(cache, dev);
+ if (dev) {
+ unique = 0;
+ break;
+ }
+ }
+
+ blkid_dev_iterate_end(iter);
+ blkid_put_cache(cache);
+
+ return unique;
+}
+
+int make_btrfs(int fd, const char *device, const char *label, char *fs_uuid,
u64 blocks[7], u64 num_bytes, u32 nodesize,
u32 leafsize, u32 sectorsize, u32 stripesize, u64 features)
{
struct btrfs_super_block super;
- struct extent_buffer *buf;
+ struct extent_buffer *buf = NULL;
struct btrfs_root_item root_item;
struct btrfs_disk_key disk_key;
struct btrfs_extent_item *extent_item;
@@ -125,7 +154,20 @@ int make_btrfs(int fd, const char *device, const char
*label,
memset(super, 0, sizeof(super));
num_bytes = (num_bytes / sectorsize) * sectorsize;
- uuid_generate(super.fsid);
+ if (fs_uuid) {
+ if (uuid_parse(fs_uuid, super.fsid) != 0) {
+ fprintf(stderr, could not parse UUID: %s\n, fs_uuid);
+ ret = -EINVAL;
+ goto out;
+ }
+ if (!test_uuid_unique(fs_uuid)) {
+ fprintf(stderr, non-unique UUID: %s\n, fs_uuid);
+ ret = -EBUSY;
+ goto out;
+ }
Why a second call to test_uuid_unique(fs_uuid) ?
+ } else {
+ uuid_generate(super.fsid);
+ }
uuid_generate(super.dev_item.uuid);
uuid_generate(chunk_tree_uuid);
diff --git a/utils.h b/utils.h
index 3c62066..4a404ae 100644
--- a/utils.h
+++ b/utils.h
@@ -39,8 +39,9 @@
#define BTRFS_UUID_UNPARSED_SIZE 37
+int test_uuid_unique(char *fs_uuid);
int make_btrfs(int fd, const char *device, const char *label,
-u64 blocks[6], u64 num_bytes, u32 nodesize,
+char *fs_uuid, u64 blocks[6], u64 num_bytes, u32 nodesize,
u32 leafsize, u32 sectorsize, u32 stripesize, u64 features);
int btrfs_make_root_dir(struct btrfs_trans_handle *trans,
struct btrfs_root *root, u64 objectid);
--
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
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
--
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
