On Mo 4.Jan'10 at 12:20:18 +0800, Yan, Zheng wrote:
Sounds like the bug reported here: http://article.gmane.org/gmane.comp.file-
systems.btrfs/4332/match=btrfs+fails+randomly. Can you try the patch
provided
in that thread?
I have sent a patch for this.
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
Google is currently in the middle of upgrading from ext2 to a more up
to date file system. We ended up choosing ext4. This thread touches
upon many of the issues we wrestled with, so I thought it would be
interesting to share. We should be sending out more details soon.
The driving performance
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
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
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
The 65k stripe length should be ignored as the stripes are
physically contiguous on disk so transfers can span stripes.
Signed-off-by: jim owens jow...@hp.com
---
fs/btrfs/volumes.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c
Returning a value greater than the caller's is ugly and prone
to dangerous future coding mistakes.
Signed-off-by: jim owens jow...@hp.com
---
fs/btrfs/extent-tree.c |3 ---
fs/btrfs/inode.c |5 ++---
fs/btrfs/volumes.c |9 +
3 files changed, 7 insertions(+), 10
The part of btrfs_map_block() that decodes the extent map and
rw/logical/length/mirror parameters is split into a routine
btrfs_map_to_stripe() so direct I/O can build multiple bios
with one lookup_extent_mapping().
The part of btrfs_map_block() that does lookup_extent_mapping()
and optional
Direct I/O needs the total number of block devices and the
struct block_device for each to allocate control structures
prior to building bios for an extent. When building a bio,
the device's base physical address of the chunk is needed.
Signed-off-by: jim owens jow...@hp.com
---
Use access_extent_buffer_page() to point at btree location of
inline compressed data so it can be inflated without a memcopy.
Signed-off-by: jim owens jow...@hp.com
---
fs/btrfs/extent_io.c | 16
fs/btrfs/extent_io.h |3 +++
2 files changed, 19 insertions(+), 0
Direct I/O needs to efficiently fetch an extent range of checksums
so an option is added to copy raw checksums into a buffer instead
of locally allocating and returning btrfs_ordered_sum structs.
Signed-off-by: jim owens jow...@hp.com
---
fs/btrfs/ctree.h |2 +-
fs/btrfs/file-item.c |
As if a Monday after a long holiday was not bad enough... this series
has some simple patches in existing btrfs code that I want to make for
btrfs directio code.
The RESEND patches 1-5 were sent to Chris in December because IMO
they have value without my directio code. You need them to apply
Direct I/O needs to fetch a single checksum based on the
extent information instead of page struct content.
Signed-off-by: jim owens jow...@hp.com
---
fs/btrfs/ctree.h |2 ++
fs/btrfs/file-item.c | 45 +
2 files changed, 47 insertions(+), 0
The code in btrfs_unplug_io_fn() to selectively unplug just the
stripes affected by a page had been previously disabled. The
unneeded code for unplug_page in __btrfs_map_block made changes
for btrfs directio more difficult so I'm removing all of it.
Signed-off-by: jim owens jow...@hp.com
---
On Mon, Jan 04, 2010 at 11:27:48AM -0500, Chris Mason wrote:
On Fri, Dec 25, 2009 at 11:11:46AM -0500, ty...@mit.edu wrote:
On Fri, Dec 25, 2009 at 02:46:31AM +0300, Evgeniy Polyakov wrote:
[1] http://samba.org/ftp/tridge/dbench/README
Was not able to resist to write a small notice,
16 matches
Mail list logo
