(2011/04/22 18:41), David Sterba wrote:
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent-tree.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 31f33ba..c97ceab 100644
---
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
We've already recorded the value in block_group-frees_space.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
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
No functional change.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
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
---
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
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
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 l...@cn.fujitsu.com
---
fs/btrfs/free-space-cache.c | 358
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
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
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.
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 suited to small
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 dste...@suse.cz
---
fs/btrfs/extent-tree.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c
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-progs
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_HOLE,
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
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 philipp.andr...@gmail.com
---
btrfs.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/btrfs.c
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
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[] = {
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 philipp.andr...@gmail.com
---
ioctl.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/ioctl.h b/ioctl.h
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
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
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 offset = start;
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 proposal,
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 the error
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 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 severity
On Mon, Apr 25, 2011 at 22:15, Ben Hutchings b...@decadent.org.uk 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
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
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
message.
I thought
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
On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge pe...@stuge.se 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 probably need
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
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: Andreas Philipp
On Mon, 2011-04-25 at 15:05 -0600, cwillu wrote:
On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge pe...@stuge.se 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
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 insertions
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):
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,
+ while(1) {
+ int c = getopt(argc, argv, r);
+ if (c 0)
+ break;
+ switch(c) {
+ case 'r':
+ optind++;
+ readonly = 1;
+
36 matches
Mail list logo
