On Sun, Mar 02, 2014 at 01:13:01PM +0400, Paul Komkoff wrote:
> Suddenly, a filesystem on SSD became corrupted. None of the usual repair
> mechanisms work.
> check_tree_block complains (have=0) for blocks in root (?), I have modified
> it to print
> buf->data and for affected
Greetings.
Suddenly, a filesystem on SSD became corrupted. None of the usual repair
mechanisms work.
check_tree_block complains (have=0) for blocks in root (?), I have modified it
to print
buf->data and for affected blocks the entire header is filled with zeros.
I have a full image if anyone wa
Hello.
So I had the filesystem that became broken. on 2.6.37 with for-linus
unstable, when accessing some directories, it was hanging hard.
I created the metadata image and can put it somewhere if you want to
use it for something.
Thanks.
--
This message represents the official view of the voic
On Thu, Jan 20, 2011 at 9:38 PM, Chris Mason wrote:
> Are you using compression?
No.
--
This message represents the official view of the voices in my head
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordom
On Wed, Jan 19, 2011 at 9:25 PM, Chris Mason wrote:
> The defrag code doesn't actually defrag. It opens up the file and
> recows all the extents and then the delayed allocation code jumps in and
> makes the biggest possible extent that it can.
>
> The reason why you're still seeing extents after
Hello.
[root@botva incoming]# btrfs fi defrag file-350mb
[root@botva incoming]# filefrag file-350mb
file-350mb: 132 extents found
[root@botva incoming]# rsync --preallocate file-350mb test
[root@botva incoming]# filefrag test
test: 1 extent found
The system is 2.6.37 with latest for-linus.
Thank
On Mon, Dec 13, 2010 at 2:23 PM, Paul Komkoff wrote:
> Hello.
I'm curious... why everyone is ignoring me?
Anyway. While trying to beat btrfs into submission I managed to make
it fill my dmesg with this:
[3301790.155343] block group 6435937189888 has 1073741824 bytes,
733720576 used 0
Hello.
Sorry if it's already fixed, but with 2.6.35.6-48.fc14.x86_64, when I
do btrfs device delete /dev/blabla /btrfs kernel moves everything
except 1 gigabyte off the device, but then fails to remove it, saying
"btrfs: unable to remove the only writeable device" to dmesg.
What's even more inter
On Wed, Nov 17, 2010 at 2:31 PM, Hugo Mills wrote:
>> == Changing RAID levels ==
>>
>> We need ioctls to change between different raid levels. Some of these
>> are quite easy -- e.g. for RAID0 to RAID1, we just halve the available
>> bytes on the fs, then queue a rebalance.
Can we please do it p
On Wed, Jan 20, 2010 at 7:28 AM, Aneesh Kumar K. V
wrote:
> the below change fixes this for me on btrfs
Thanks a million, now I guess we're waiting for Chris to pull it.
Will it qualify for stable update?
--
This message represents the official view of the voices in my head
--
To unsubscribe fro
On Thu, Jan 14, 2010 at 8:33 PM, Paul Komkoff wrote:
> If it's fixed in latest tree it's fine, I guess that fix isn't in
> fedora's 2.6.32.3
Sorry for popping up again, but did anyone fix this/verified there's
no problem in recent kernels? For some reasons I can
On Thu, Jan 14, 2010 at 7:20 PM, Chris Mason wrote:
> The file size should still be 4 bytes I think, even if we allocate 4096.
Yes, to clarify - I changed the code to be
fallocate(fd, 0, 0, 4);
and then
posix_fallocate(fd, 0, 4);
(which is the same I guess)
and tried it on different filesys
2010/1/14 i :
> Nowhere there it is said that size is ceil()'d to a blocksize. Moreover, I
> never saw an app that does fallocate() and then ftruncate() - every single
> app out there assumes that posix_fallocate (and fallocate, fwiw), while may
> allocate more space, will set the file size to s
On Thu, Jan 14, 2010 at 5:27 PM, Roland Dreier wrote:
> My fallocate man page says:
>
> Because allocation is done in block size chunks, fallocate() may
> allocate a larger range than that which was specified.
>
> so the btrfs behavior seems OK to me.
>
> You say this is a regression.
Oh hai
Sorry if it's already fixed, but at least in fedora's
2.6.32.3-10.fc12.i686.PAE btrfs has a regression which can be
illustrated by running the following dumb test:
=== cut here ===
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include
#include
#include
int main() {
int fd = open(
On Wed, Apr 29, 2009 at 8:32 PM, Tracy Reed wrote:
> Note that this will be a problem that btrfs must properly manage. And
> it must be done MUCH better than a certain previously semi-popular
> filesystem did. The expectation needs to be set that due to the much
I don't think it's workable or fea
16 matches
Mail list logo
