On 12/18/2012 06:02 PM, Liu Bo wrote:
On Tue, Dec 18, 2012 at 02:26:50PM -0800, Wade Cline wrote:
On 12/18/2012 12:49 AM, Miao Xie wrote:
On tue, 18 Dec 2012 15:30:51 +0800, Liu Bo wrote:
On Mon, Dec 17, 2012 at 11:13:25PM -0800, cli...@linux.vnet.ibm.com wrote:
From: Wade Cline
v1
On 12/18/2012 03:01 PM, Chris Samuel wrote:
On 19/12/12 09:26, Wade Cline wrote:
Yeah. Basically, if we create a btrfs filesystem with a 4k blocksize
then that filesystem is incompatible with architectures such as PowerPC
and MIPS which have a page size larger than 4k.
What happens currently
On 12/18/2012 12:49 AM, Miao Xie wrote:
On tue, 18 Dec 2012 15:30:51 +0800, Liu Bo wrote:
On Mon, Dec 17, 2012 at 11:13:25PM -0800, cli...@linux.vnet.ibm.com wrote:
From: Wade Cline
v1 -> v2:
- Added Signed-off-by tag (it's kind of important).
This patch is only an RFC. My inter
Hi Swâmi,
On 12/03/2012 04:09 AM, Hugo Mills wrote:
On Mon, Dec 03, 2012 at 12:54:30PM +0100, Swâmi Petaramesh wrote:
Hi folks,
My laptop is a Core i3-2310M with 4 GB RAM, running BTRFS on a 1 TB HD.
I run Ubuntu 12.10 Quantal, kernel 3.5.0-19-generic 64-bit.
Try 3.7. That's had some s
On 10/25/2012 12:09 PM, Alex Lyakas wrote:
Wade, thanks.
Yes, with the preallocated extent I saw the behavior you describe, and
it makes perfect sense to alloc a new EXTENT_DATA in this case.
In my case, I did another simple test:
Before:
item 4 key (257 INODE_ITEM 0) itemoff 3593 item
Hi Alex,
Someone correct me if I am wrong, but I'm pretty sure that the purpose of
'nodatacow' is to prevent the location of extents on the disk itself from
moving, however, it may be necessary to allocate more extents in the metadata
(which I presume are represented by EXTENT_DATA) in order to d
On 10/03/2012 10:58 AM, Theodore Ts'o wrote:
To clarify, the EXT2_FEATURE_INCOMPAT_FILETYPE flag indicates that
there _may_ be file type information in the directory entry (and so
only the low 8 bits of name_len should be considered part of the name
length), but it does not guarantee that it wil
On 10/02/2012 02:08 PM, Theodore Ts'o wrote:
On Tue, Oct 02, 2012 at 12:02:22PM -0700, Wade Cline wrote:
Hello Theodore Ts'o,
Is there a function similar to ext2fs_dir_iterate2() that will call a hook
function on an ext2_dir_entry_2 structure and not an ext2_dir_entry
structure?
Th
Hi Josef,
This patch is causing fragmentation with O_DIRECT on preallocated extents
located
-after- the first write to the preallocated extent. This happens regardless of
nodatacow/autodefrag mount options.
Thank you,
Wade
On 10/01/2012 12:00 PM, Josef Bacik wrote:
I need everybody to go ove
in a patch that adds a function, say,
ext2_dir_entry_upgrade(struct ext2_dir_entry *old, struct ext2_dir_entry_2 *new)
that will convert one structure to the other and take into account the
endianness
of the machine? This would be better than just ad-hoc fixing the code in btrfs.
Thank you,
Wade Cl
On 09/28/2012 01:20 PM, Hugo Mills wrote:
On Sat, Sep 29, 2012 at 12:02:23AM +0600, Roman Mamedov wrote:
On Fri, 28 Sep 2012 18:44:07 +0200
Goffredo Baroncelli wrote:
This means that the ration of space physically allocated on the disk and
the space available is 7GB/10GB = 0.7 . So on 135GB
On 09/14/2012 06:59 AM, David Sterba wrote:
On Wed, Sep 12, 2012 at 04:21:56PM -0700, cli...@linux.vnet.ibm.com wrote:
Defining __KERNEL__ before the file, or any file that
includes this file, will let PPC64 know to use unsigned long long
for u64 instead. This patch adds the defines and fixes th
On 09/11/2012 12:42 PM, Josef Bacik wrote:
Wade Cline reported a problem where he was getting garbage and warnings when
writing to a preallocated range via O_DIRECT. This is because we weren't
creating our normal pinned extent_map for the range we were writing to,
which was causing all sor
Hi,
I was doing some fragmentation tests on preallocated extents on Josef's
btrfs-next branch (commit 8fe3b6) with the O_DIRECT flag enabled and
noticed some strange behavior. Writing to a preallocated extent
currently triggers a WARN_ON on in the kernel, triggers a csum error for
what appear
14 matches
Mail list logo
