init_ipath() can return an ERR_PTR(-ENOMEM).
Signed-off-by: Dan Carpenter
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 offset,
u64 root, void *
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 blocks that return zeroes) that seems like a
fairly nasty surprise for O_SYNC
Hi,
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 made it to disk.
>
> Given that a fallocate without FALLOC_FL_KEEP_SIZE very much is a data
> operation (it adds new bl
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 made it to disk.
> >
> > Given that a fallocate without F
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 tran
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 filesyst
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()
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
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 some part of the kernel has set a btrfs da
2011/11/16 Chris Mason :
> 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 some par
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
---
fs/btrfs/inode.c |6 --
1 files changed, 4 insertions(+), 2 deletions(
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 right thing
> > > and make sure the update actually
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 differ
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 fil
The location of the btrfs-progs repository has been changed.
This patch updates the documentation accordingly.
Signed-off-by: Arnd Hannemann
---
Documentation/filesystems/btrfs.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesyste
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
Signed-off-by: Jan Schmidt
Thanks,
-Jan
> 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
For the user it is confusing to find something like:
[10197.627710] new size for /dev/mapper/vg0-usr_share is 3221225472
in kernel log, because it doesn't point directly to btrfs.
This patch prefixes those messages with "btrfs:" like other btrfs
related printks.
Signed-off-by: Arnd Hannemann
---
Am 14.11.2011 19:24, schrieb Arnd Hannemann:
> Am 14.11.2011 15:57, schrieb Arnd Hannemann:
>
>> I'm using btrfs for my /usr/share/ partition and keep getting the following
>> error
>> while installing a debian package which should take no more than 228 MB:
>>
>> Unpacking texlive-fonts-extra (fr
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 t
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.
--M
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 (l
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 b
Signed-off-by: Marcos Paulo de Souza
---
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 @@ void btrfs_set_lock_block
-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 good
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
29 matches
Mail list logo
