init_ipath() can return an ERR_PTR(-ENOMEM).
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index ed11d38..b72ee47 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -256,6 +256,11 @@ static int scrub_print_warning_inode(u64 inum, u64
Hi,
On Wed, 2011-11-16 at 11:54 +0100, Jan Kara wrote:
Hello,
On Wed 16-11-11 09:43:08, Steven Whitehouse wrote:
On Wed, 2011-11-16 at 03:42 -0500, Christoph Hellwig wrote:
It seems all filesystems but XFS ignore O_SYNC for fallocate, and never
make sure the size update transaction
On Wed, Nov 16, 2011 at 03:42:56AM -0500, Christoph Hellwig wrote:
It seems all filesystems but XFS ignore O_SYNC for fallocate, and never
make sure the size update transaction made it to disk.
Given that a fallocate without FALLOC_FL_KEEP_SIZE very much is a data
operation (it adds new
On Wed, Nov 16, 2011 at 11:54:13AM +0100, Jan Kara wrote:
Yeah, only that nobody calls that fsync() automatically if the fd is
O_SYNC if I'm right. But maybe calling fdatasync() on the range which was
fallocated from sys_fallocate() if the fd is O_SYNC would do the trick for
most
On Wed 16-11-11 07:45:50, Christoph Hellwig wrote:
On Wed, Nov 16, 2011 at 11:54:13AM +0100, Jan Kara wrote:
Yeah, only that nobody calls that fsync() automatically if the fd is
O_SYNC if I'm right. But maybe calling fdatasync() on the range which was
fallocated from sys_fallocate() if
On Wed, Nov 16, 2011 at 02:39:15PM +0100, Jan Kara wrote:
This would work fine with XFS and be equivalent to what it does for
O_DSYNC now. But I'd rather see every filesystem do the right thing
and make sure the update actually is on disk when doing O_(D)SYNC
operations.
OK, I don't
2011/11/16 Chris Mason chris.ma...@oracle.com:
On Tue, Nov 15, 2011 at 09:19:53AM +0100, Christian Brunner wrote:
Hi,
this time I've hit a new bug. This happened while ceph was rebuilding
his filestore (heavy io).
The btrfs version is from 3.2-rc1, applied to a 3.0 kernel.
This one means
Round inode bytes and delalloc bytes up to real blocksize before
converting to sector size. Otherwise eg. files smaller than 512
are reported with zero blocks due to incorrect rounding.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/inode.c |6 --
1 files changed, 4
On Wed, Nov 16, 2011 at 04:57:55PM +0100, Jan Kara wrote:
I agree with you that userspace shouldn't have to call fsync. What I
meant is that sys_fallocate() or do_fallocate() can call
generic_write_sync(file, pos, len), and that would be completely
transparent to userspace.
That's different
On Wed, Nov 16, 2011 at 04:57:55PM +0100, Jan Kara wrote:
On Wed 16-11-11 08:42:34, Christoph Hellwig wrote:
On Wed, Nov 16, 2011 at 02:39:15PM +0100, Jan Kara wrote:
This would work fine with XFS and be equivalent to what it does for
O_DSYNC now. But I'd rather see every filesystem do
The location of the btrfs-progs repository has been changed.
This patch updates the documentation accordingly.
Signed-off-by: Arnd Hannemann a...@arndnet.de
---
Documentation/filesystems/btrfs.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
I have some kind of corruption in my btrfs file system that causes kernel
segmentation faults when I try to delete files in my browser cache. Let me
know if you are interested in having any additional information besides what
is below. Thanks.
root@berna:~# uname -a
Linux berna 2.6.38-bpo.2-amd64
On 16.11.2011 09:28, Dan Carpenter wrote:
init_ipath() can return an ERR_PTR(-ENOMEM).
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
Thanks,
-Jan
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index ed11d38..b72ee47 100644
---
On Wed, Nov 16, 2011 at 11:18:06AM -0500, Chris Mason wrote:
On Wed, Nov 16, 2011 at 04:57:55PM +0100, Jan Kara wrote:
On Wed 16-11-11 08:42:34, Christoph Hellwig wrote:
On Wed, Nov 16, 2011 at 02:39:15PM +0100, Jan Kara wrote:
This would work fine with XFS and be equivalent to what it
On Wed, Nov 16, 2011 at 11:35:40AM -0800, Mark Fasheh wrote:
We should do it per FS though, I'll patch up btrfs.
I agree about doing it per FS. Ocfs2 just needs a one-liner to mark the
journal transaction as synchronous.
Joel, here's an (untested) patch to fix this in Ocfs2.
--Mark
Hi,
On Wed, Nov 16, 2011 at 04:39:21PM +, Tim Crone wrote:
root@berna:~# uname -a
Linux berna 2.6.38-bpo.2-amd64 #1 SMP Mon Jun 6 15:24:02 UTC 2011
x86_64 GNU/Linux
2.6.38 is quite old from btrfs perspective and it's highly possible that
the bug you've hit is already fixed. Try newer
I wrote a small patch to improve allocation on differently sized raid devices.
With 2.6.38 I frequently ran into a no space left error that I attribute to
this. But I'm not entierly sure. The fs was an 8 device -d raid0 -m raid10.
The used space was the same across all devices. 5 were full and 3
Signed-off-by: Marcos Paulo de Souza marcos.m...@gmail.com
---
fs/btrfs/locking.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
index d77b67c..8abb870 100644
--- a/fs/btrfs/locking.c
+++ b/fs/btrfs/locking.c
@@ -48,7 +48,6 @@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/23/2011 04:01 PM, Ilya Dryomov wrote:
Hello,
This patch series adds an initial implementation of restriper (it's
a clever name for relocation framework that allows to do selective
profile changing and selective balancing with some goodies
Suppose there are two bitmaps [0, 256], [256, 512] and one extent
[100, 120] in the free space cache, and we want to setup a cluster
with offset=100, bytes=50.
In this case, there will be only one bitmap [256, 512] in the temporary
bitmaps list, and then setup_cluster_bitmap() won't search bitmap
There are various bugs in block group trimming:
- It may trim from offset smaller than user-specified offset.
- It may trim beyond user-specified range.
- It may leak free space for extents smaller than specified minlen.
- It may truncate the last trimmed extent thus leak free space.
- With mixed
On 17.11.2011 01:27, Thomas Schmidt wrote:
I wrote a small patch to improve allocation on differently sized raid devices.
With 2.6.38 I frequently ran into a no space left error that I attribute to
this. But I'm not entierly sure. The fs was an 8 device -d raid0 -m raid10.
The used space was
22 matches
Mail list logo
