No material changes are made.
---
Makefile | 10 +-
convert.c => convert/convert.c | 803 +---
convert/convert.h | 76
convert/ext2.c | 791 +++
4 files changed, 87
Filesystems need to provide a function open_blah that fills a struct
convert_fs with some information and three function pointers.
The function pointers are:
- cache_free_extents, which takes a struct extent_io_tree and marks all
extents not being used by the filesystem as DIRTY
- copy_inodes, wh
A filesystem can have disk extents in arbitrary places on the disk, as
well as extents that must be read into memory because they have
compression or encryption btrfs doesn't support. These extents can be
passed to the new extent iteration functions, which will handle all the
details of alignment,
An extent_io_tree is used for all free space information. This allows
removal of ext2_alloc_block and ext2_free_block, and makes
create_ext2_image less ext2-specific.
---
convert.c | 154 +++--
1 files changed, 99 insertions(+), 55 deletions
2010/3/17 Hubert Kario :
>
> Read further, Sun did provide a way to enable the compare step by using
> "verify" instead of "on":
> zfs set dedup=verify
I have tested ZFS deduplication on the same data set that I'm using to
test btrfs. I used a 5-element radiz, dedup=on, which uses SHA256 for
ZFS
On Fri, Mar 19, 2010 at 9:59 PM, Josef Bacik wrote:
> On Fri, Mar 19, 2010 at 11:09:25AM +0800, Yan, Zheng wrote:
>> On Thu, Mar 18, 2010 at 11:47 PM, Josef Bacik wrote:
>> > A user reported a bug a few weeks back where if he set max_extent=1m and
>> > then
>> > did a dd and then stopped it, we
We don't actually check the return value of btrfs_read_block_groups, so we can
possibly succeed to mount, but then fail to say read the superblock xattr for
selinux which will cause the vfs code to deactivate the super. This is a
problem because in find_free_extent we just assume that we will find
As Yan pointed out, theres not much reason for all this complicated math to
account for file extents being split up into max_extent chunks, since they are
likely to all end up in the same leaf anyway. Since there isn't much reason to
use max_extent, just remove the option altogether so we have one
Remove duplicated #include('s) in
fs/btrfs/ioctl.c
Signed-off-by: Huang Weiyi
---
fs/btrfs/ioctl.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2845c6c..5c9f8b3 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -48,7 +
Because we account for reserved space we get from the allocator before we
actually account for allocating delalloc space, we can have a small window where
the amount of "used" space in a space_info is more than the total amount of
space in the space_info. This will cause a overflow in our check, s
On Fri, Mar 19, 2010 at 11:09:25AM +0800, Yan, Zheng wrote:
> On Thu, Mar 18, 2010 at 11:47 PM, Josef Bacik wrote:
> > A user reported a bug a few weeks back where if he set max_extent=1m and
> > then
> > did a dd and then stopped it, we would panic. This is because I
> > miscalculated
> > how
On Fri, Mar 19 2010, Shaohua Li wrote:
> On Fri, Mar 19, 2010 at 04:22:11PM +0800, Jens Axboe wrote:
> > On Fri, Mar 19 2010, Shaohua Li wrote:
> > > On Fri, Mar 19, 2010 at 08:59:48AM +0800, Shaohua Li wrote:
> > > > On Thu, Mar 18, 2010 at 08:53:13PM +0800, Chris Mason wrote:
> > > > > On Thu, Ma
On Fri, Mar 19, 2010 at 04:22:11PM +0800, Jens Axboe wrote:
> On Fri, Mar 19 2010, Shaohua Li wrote:
> > On Fri, Mar 19, 2010 at 08:59:48AM +0800, Shaohua Li wrote:
> > > On Thu, Mar 18, 2010 at 08:53:13PM +0800, Chris Mason wrote:
> > > > On Thu, Mar 18, 2010 at 09:42:57AM +0800, Shaohua Li wrote:
On Fri, Mar 19 2010, Shaohua Li wrote:
> On Fri, Mar 19, 2010 at 08:59:48AM +0800, Shaohua Li wrote:
> > On Thu, Mar 18, 2010 at 08:53:13PM +0800, Chris Mason wrote:
> > > On Thu, Mar 18, 2010 at 09:42:57AM +0800, Shaohua Li wrote:
> > > > Btrfs uses below equation to calculate ra_pages:
> > > >
Hello!
I joined the list after this thread:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/4589
but I just found it via google, as I've hit this same bug with a
"real" use-case: the NVIDIA CUDA developer kit.
Upon final installation of this package, I hit the ([Error 31] Too
many Links)
15 matches
Mail list logo