Hello all.
What we have:
SL6 - kernel 2.6.32-131.2.1.el6.x86_64
btrfs on mdadm RAID5 with 8 HDD - 27T partition.
I see this at top:
1182 root 20 0 000 R 100.0 0.0 16:39.73
[btrfs-delalloc-]
And LA is grow. What is this and how can I fix it?
--
Best regards,
Proskurin
On Sun, Jun 26, 2011 at 10:10:22PM +0100, Hugo Mills wrote:
I've just updated the btrfs-progs integration branch I've been
keeping. Not a huge amount new since last time:
Andreas Philipp (1):
print parent ID in btrfs subvolume list
dunno if this has been mentioned already, but this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27.06.2011 14:43, David Sterba wrote:
On Sun, Jun 26, 2011 at 10:10:22PM +0100, Hugo Mills wrote:
I've just updated the btrfs-progs integration branch I've been
keeping. Not a huge amount new since last time:
Andreas Philipp (1):
print
On Monday 27 of June 2011 11:04:06 Proskurin Kirill wrote:
Hello all.
What we have:
SL6 - kernel 2.6.32-131.2.1.el6.x86_64
btrfs on mdadm RAID5 with 8 HDD - 27T partition.
I see this at top:
1182 root 20 0 000 R 100.0 0.0 16:39.73
[btrfs-delalloc-]
And LA is
On Mon, Jun 27, 2011 at 03:03:30PM +0200, Andreas Philipp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27.06.2011 14:43, David Sterba wrote:
On Sun, Jun 26, 2011 at 10:10:22PM +0100, Hugo Mills wrote:
I've just updated the btrfs-progs integration branch I've been
keeping.
Hi Folks (please cc: any replies to me),
I have modified GNU Make to use checksums rather than
timestamps. I would like the operating system and/or
filesystem to compute and provide the checksums, because it
can safely cache them.
Since btrfs checksums its files, I am trying to transfer its
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. We need to match solaris
here, and the definitions are
*o* If /whence/ is SEEK_HOLE,
Since Ext4 has its own lseek we need to make sure it handles
SEEK_HOLE/SEEK_DATA. For now just do the same thing that is done in the generic
case, somebody else can come along and make it do fancy things later. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/ext4/file.c | 21
This converts everybody to handle SEEK_HOLE/SEEK_DATA properly. In some cases
we just return -EINVAL, in others we do the normal generic thing, and in others
we're simply making sure that the properly due-dilligence is done. For example
in NFS/CIFS we need to make sure the file size is update
In order to handle SEEK_HOLE/SEEK_DATA we need to implement our own llseek.
Basically for the normal SEEK_*'s we will just defer to the generic helper, and
for SEEK_HOLE/SEEK_DATA we will use our fiemap helper to figure out the nearest
hole or data. Currently this helper doesn't check for
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and will
adjust as necessary.
Cc: x...@oss.sgi.com
Signed-off-by: Josef Bacik jo...@redhat.com
---
255 | 71
255.out
Hi everyone,
The for-linus branch of the btrfs unstable tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
Has our current set of fixes. Linus will probably notice the head
commit was from this morning. I reordered a refcount bump inside the
lock that
On 2011-06-27, at 12:02 PM, Josef Bacik wrote:
This is a test to make sure seek_data/seek_hole is acting like it does on
Solaris. It will check to see if the fs supports finding a hole or not and
will
adjust as necessary.
diff --git a/src/seek-tester.c b/src/seek-tester.c
new file mode
On 06/27/2011 02:32 PM, Andreas Dilger wrote:
On 2011-06-27, at 12:02 PM, Josef Bacik wrote:
snip
+
+#define SEEK_DATA 3
+#define SEEK_HOLE 4
These should probably be #ifndef SEEK_DATA so that gcc doesn't complain
in the future when these are added to a standard header.
Good
On 06/27/2011 02:02 PM, Josef Bacik wrote:
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns
out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. We need to match solaris
here, and
Hi,
I have some errors in dmesg:
[ 542.255788] ata1.00: exception Emask 0x0 SAct 0xff SErr 0x0 action 0x0
[ 542.255797] ata1.00: irq_stat 0x4008
[ 542.255805] ata1.00: failed command: READ FPDMA QUEUED
[ 542.255821] ata1.00: cmd 60/00:00:1a:b7:7a/04:00:1d:00:00/40 tag 0
ncq 524288 in
ping?
On 06/20/2011 10:59 AM, Liu Bo wrote:
In btrfs's in-memory inode, there is a btrfs_key which has the structure:
- key.objectid
- key.type
- key.offset
however, we only use key.objectid to search, to check or something else,
and to reduce in-memory inode size I just keep what is
Excerpts from Liu Bo's message of 2011-06-19 22:59:15 -0400:
In btrfs's in-memory inode, there is a btrfs_key which has the structure:
- key.objectid
- key.type
- key.offset
however, we only use key.objectid to search, to check or something else,
and to reduce in-memory inode size I just
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c |1 +
fs/btrfs/ioctl.c | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff
Hi Zhong,
On Mo, 27 Jun 2011, Zhong, Xin wrote:
We met this situation in meego too:
https://bugs.meego.com/show_bug.cgi?id=18156
Ah, good to hear that I am not the only one.
(Last time I was told: It only happens to you! until the real bug
was found ;-)
I am now working on a patch to handle
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
V1 - V2: unnecessary BUG_ON was deleted
fs/btrfs/ioctl.c | 10 +-
1 files changed, 9 insertions(+), 1
21 matches
Mail list logo
