>> +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
> + while(1) {
> + int c = getopt(argc, argv, "r");
> + if (c < 0)
> + break;
> + switch(c) {
> + case 'r':
> + optind++;
> + readonly = 1;
> +
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
> ---
> btrfs_cmds.c | 44
> 1 files changed, 36 insertions(+), 8
Andreas Philipp wrote:
> There is kernel side support for the creation of read-only snapshots
> for some time now, but I did not find any patches for the userspace
> btrfs utilites. Thus I created this patchset which is tested and
> working with kernel version 2.6.39-rc2.
>
> Andreas Philipp (5):
On Mon, 25 Apr 2011 16:50:43 -0400, Chris Mason wrote:
> Excerpts from Miao Xie's message of 2011-04-22 06:12:24 -0400:
>> Since we have implemented the delayed update of the inode, we can also
>> delayed to insert the initial inode, then we can merge the inode update
>> and the initial inode inser
On Mon, 2011-04-25 at 15:05 -0600, cwillu wrote:
> On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge wrote:
> > Maik Zumstrull wrote:
> >> >> Bug at fs/btrfs/free-space-cache.c:1246
> >> >> Bug type: invalid opcode:
> >> >> Kernel not tainted, running on an ASUSTek 1005HAG
> >> >> EIP is at btrfs_
Excerpts from Goffredo Baroncelli's message of 2011-04-25 17:34:46 -0400:
> 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: Andrea
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
> ---
> btrfs_cmds.c | 44
>
On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge wrote:
> Maik Zumstrull wrote:
>> >> Bug at fs/btrfs/free-space-cache.c:1246
>> >> Bug type: invalid opcode:
>> >> Kernel not tainted, running on an ASUSTek 1005HAG
>> >> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
>> >
>> > You will probabl
Excerpts from Miao Xie's message of 2011-04-22 06:12:24 -0400:
> Since we have implemented the delayed update of the inode, we can also
> delayed to insert the initial inode, then we can merge the inode update
> and the initial inode insertions to one insertion.
Awesome. With things separate from
Maik Zumstrull wrote:
> >> Bug at fs/btrfs/free-space-cache.c:1246
> >> Bug type: invalid opcode:
> >> Kernel not tainted, running on an ASUSTek 1005HAG
> >> EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
> >
> > You will probably need to provide a more complete copy of the panic
> > messa
Excerpts from Chris Mason's message of 2011-04-25 13:15:58 -0400:
> Excerpts from Li Zefan's message of 2011-04-25 04:57:47 -0400:
> > Currently btrfs stores the highest objectid of the fs tree, and it always
> > returns (highest+1) inode number when we create a file, so inode numbers
> > won't be
On Mon, Apr 25, 2011 at 22:15, Ben Hutchings wrote:
> On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:
>> By simply stressing the system with some I/O, I can make it crash within
>> seconds. I'm not setting a higher severity because the bug is in an
>> experimental file system in an exper
On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:
> Package: linux-image-2.6.39-rc4-686-pae
> Version: 2.6.39~rc4-1~experimental.1
> Severity: normal
> Tags: experimental
>
> By simply stressing the system with some I/O, I can make it crash within
> seconds. I'm not setting a higher severit
Excerpts from Li Zefan's message of 2011-04-25 04:57:47 -0400:
> Currently btrfs stores the highest objectid of the fs tree, and it always
> returns (highest+1) inode number when we create a file, so inode numbers
> won't be reclaimed when we delete files, so we'll run out of inode numbers
> as we
On 04/25/2011 09:02 AM, Nick Bowler wrote:
Hi Nick,
> * File A (sparse file created by lseek/write beyond end-of-file):
>
> data | hole 0 | data || hole 1 (virtual)
>
> * File B (sparse file created by truncate beyond end-of-file):
>
> data | hole 0 || hole 1 (virtual)
>
> Excluding th
Hi Eric,
On 2011-04-22 07:06 -0600, Eric Blake wrote:
> I've created a request to standardize SEEK_HOLE and SEEK_DATA in the
> next revision of POSIX; comments are welcome to make sure that everyone
> is happy with wording:
> http://austingroupbugs.net/view.php?id=415
Reading through your proposa
Eric Blake wrote:
> On 04/24/2011 11:49 AM, Jamie Lokier wrote:
> >> My problem with FIND_* is that we are messing with the well understood
> >> semantics of lseek().
> >
> > fcntl() looks a better fit for FIND_HOLE/DATA anyway.
>
> With fcntl(), it would have to be something like:
>
> off_t off
Signed-off-by: Andreas Philipp
---
man/btrfs.8.in | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..b59bc6f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
.SH NAME
btrfs \- control a btrfs filesyst
Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.
Signed-off-by: Andreas Philipp
---
ioctl.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/ioctl.h b/ioctl.h
index 776d7a9..358f814 10064
Signed-off-by: Andreas Philipp
---
ioctl-test.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ioctl-test.c b/ioctl-test.c
index 7cf3bc2..1c27d61 100644
--- a/ioctl-test.c
+++ b/ioctl-test.c
@@ -22,6 +22,7 @@ unsigned long ioctls[] = {
BTRFS_IOC_INO_LOOKUP,
Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.
Signed-off-by: Andreas Philipp
---
btrfs.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index 46314cf..f70d64b
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
---
btrfs_cmds.c | 44
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/btrfs_cmds
There is kernel side support for the creation of read-only snapshots
for some time now, but I did not find any patches for the userspace
btrfs utilites. Thus I created this patchset which is tested and
working with kernel version 2.6.39-rc2.
Andreas Philipp (5):
Add support for read-only subvolu
On 04/24/2011 11:49 AM, Jamie Lokier wrote:
>> My problem with FIND_* is that we are messing with the well understood
>> semantics of lseek().
>
> fcntl() looks a better fit for FIND_HOLE/DATA anyway.
With fcntl(), it would have to be something like:
off_t offset = start;
if (fcntl (fd, F_FIND_H
Excerpts from David Morgado's message of 2011-04-24 21:24:16 -0400:
> Hi, btrfs-progs patches for read only snapshots aren't in Chris
> repository yet but btrfs already has support for that in place so,
> someone forgot about this?
>
> It appears that some new patches are coming to Chris btrfs-pro
Excerpts from Tsutomu Itoh's message of 2011-04-25 02:25:58 -0400:
> (2011/04/22 18:41), David Sterba wrote:
> > Signed-off-by: David Sterba
> > ---
> > fs/btrfs/extent-tree.c |6 --
> > 1 files changed, 0 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/btrfs/extent-tree.c b/fs/btr
On 04/22/2011 09:28 AM, Chris Mason wrote:
> Excerpts from Li Zefan's message of 2011-04-21 20:55:40 -0400:
>> Chris Mason wrote:
>>> Excerpts from liubo's message of 2011-04-21 03:58:21 -0400:
The current code relogs the entire inode every time during fsync log,
and it is much better sui
Li Zefan wrote:
> Currently btrfs stores the highest objectid of the fs tree, and it always
> returns (highest+1) inode number when we create a file, so inode numbers
> won't be reclaimed when we delete files, so we'll run out of inode numbers
> as we keep create/delete files in 32bits machines.
>
This is similar to block group caching.
We dedicate a special inode in fs tree to save free ino cache.
At the very first time we create/delete a file after mount, the free ino
cache will be loaded from disk into memory. When the fs tree is commited,
the cache will be written back to disk.
To kee
There's a potential problem in 32bit system when we exhaust 32bit inode
numbers and start to allocate big inode numbers, because btrfs uses
inode->i_ino in many places.
So here we always use BTRFS_I(inode)->location.objectid, which is an
u64 variable.
There are 2 exceptions that BTRFS_I(inode)->l
Extract out block group specific code from lookup_free_space_inode(),
create_free_space_inode(), load_free_space_cache() and
btrfs_write_out_cache(), so the code can be used to read/write
free ino cache.
Signed-off-by: Li Zefan
---
fs/btrfs/free-space-cache.c | 358 -
Currently btrfs stores the highest objectid of the fs tree, and it always
returns (highest+1) inode number when we create a file, so inode numbers
won't be reclaimed when we delete files, so we'll run out of inode numbers
as we keep create/delete files in 32bits machines.
This fixes it, and it wor
So we can re-use the code to cache free inode numbers.
The change is quite straightforward. Two new structures are introduced.
- struct btrfs_free_space_ctl
We move those variables that are used for caching free space from
struct btrfs_block_group_cache to this new struct.
- struct btrfs_fr
No functional change.
Signed-off-by: Li Zefan
---
fs/btrfs/free-space-cache.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 3af64c6..0e23bba 100644
--- a/fs/btrfs/free-space-cache.c
+++
We've already recorded the value in block_group->frees_space.
Signed-off-by: Li Zefan
---
fs/btrfs/free-space-cache.c | 15 ---
fs/btrfs/free-space-cache.h |1 -
2 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-ca
Currently btrfs stores the highest objectid of the fs tree, and it always
returns (highest+1) inode number when we create a file, so inode numbers
won't be reclaimed when we delete files, so we'll run out of inode numbers
as we keep create/delete files in 32bits machines.
This patchset aims to fix
37 matches
Mail list logo
