If we runt the direct IO, we should not run auto defrag, because it may
introduce buffered IO vs direcIO problem, and make direct IO slow down.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/btrfs/inode.c
We forget to release the reserved space in the error path of delalloc
reservatiom, fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3d3e2c1..1cd71b2
Steps to reproduce:
# mkfs.btrfs disk
# mount disk mnt
# dd if=/dev/zero of=mnt/file bs=512 seek=5 count=8
# fallocate -p -o 2048 -l 16384 mnt/file
# dd if=/dev/zero of=mnt/file bs=4096 seek=3 count=8 conv=notrunc,nocreat
# umount mnt
# dmesg
WARNING: at fs/btrfs/inode.c:7140
Since we can pre-allocate the space past EOF, we should be able to reclaim
that space if we need. This patch implements it by removing the EOF check.
Though the manual of fallocate command says we can use truncate command to
reclaim the pre-allocated space which past EOF, but because truncate
ret variant may be set to 0 if we read page successfully, but it might be
released before we lock it again. On this case, if we fail to allocate a
new page, we will return 0, it is wrong, fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/inode.c | 3 +--
1 file changed, 1
---
MDaemon has detected restricted attachments within an email message
---
From : linux-btrfs@vger.kernel.org
To: bomsa...@bird.in
Subject : Returned
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
when I was testing what I thought might be
My previous reply was incorrect in one point - the data is never copied from
the transaction log into the sparse datafiles, instead the application writes
the same data independently to both locations.
Also, I failed to mention that the files are memmapped, and it's possible that
the write
Dear all,
thanks for developing btrfsck!
Now, I'd like to contribute -as far as I can. I'm not a developer, but I
do have some linux-experience.
I've been using btrfsck on two 3TB HDDs (mirrored) for a while now under
Kernel 3.0. Now it's corrupt. I had some hard resets of the machine
-which
more important, when will the emacs sendrecv.el be ready?
On Tue, Dec 4, 2012 at 9:29 PM, Ins insfo...@gmail.com wrote:
Hello all,
The implementation of send/receive is very cool.
But I wonder whether there are any plans to support these features
below or not,
1. support
What the emacs sendrecv.el does?
2012/12/6 james northrup northrup.ja...@gmail.com:
more important, when will the emacs sendrecv.el be ready?
On Tue, Dec 4, 2012 at 9:29 PM, Ins insfo...@gmail.com wrote:
Hello all,
The implementation of send/receive is very cool.
But I wonder
Maybe you can use systemtap to track what's going on.
2012/12/6 Sylvain Alain d2racing...@gmail.com:
Hi everyone, I'm running btrfs since octobre 2012 and I would like to
understand 2 behavior that I noticed.
1. When I delete a big directory, sometimes it can hang my box for 1
minutes or so,
On Wed, Dec 05, 2012 at 05:42:51PM +, Thorn Roby wrote:
My previous reply was incorrect in one point - the data is never copied from
the transaction log into the sparse datafiles, instead the application writes
the same data independently to both locations.
Also, I failed to mention that
13 matches
Mail list logo