On Sat, Apr 4, 2015 at 4:33 AM, Filipe David Manana fdman...@gmail.com wrote:
On Sat, Apr 4, 2015 at 12:36 AM, Justin Maggard jmaggar...@gmail.com wrote:
Hi,
We're hitting a consistently reproducible ENOSPC condition with a
simple test case:
# truncate -s 1T btrfs.fs
# mkfs.btrfs btrfs.fs
On Mon, Apr 6, 2015 at 1:08 PM, Martin deve...@imagmbh.de wrote:
Am Montag, 6. April 2015, 09:45:10 schrieb Chris Murphy:
On Mon, Apr 6, 2015 at 5:40 AM, Martin deve...@imagmbh.de wrote:
Hello!
I have to recover a corrupt btrfs. The size is approx 4.5 TB. The fs
became
corrupt by
Am Montag, 6. April 2015, 09:45:10 schrieb Chris Murphy:
On Mon, Apr 6, 2015 at 5:40 AM, Martin deve...@imagmbh.de wrote:
Hello!
I have to recover a corrupt btrfs. The size is approx 4.5 TB. The fs
became
corrupt by failure of a hardware-raid.
What raid level? What kind of failure?
Hello BTRFS developers,
I am requesting your opion.
I am planning to design and implement DFS version of BTRFS.
Roughly it will be done by
1. Extending current DeviceID to NodeID:DeviceID to support multi-node, and
2. Implementing inter-node data and meta-data access over TCP.
Do you
This matches the logic of ext4. I think it's more
correct passing (offset + len) to inode_newsize_ok()
rather than rounding up to block size.
The call can be skipped in some cases too. It works for
me but I'm new to this code so I might miss something.
Let me know what you think.
Davide Italiano
- We call inode_size_ok() only if FL_KEEP_SIZE isn't specified.
- As an optimisation we can skip the call if (off + len)
isn't greater than the current size of the file. This operation
is called under the lock so the less work we do, the better.
- If we call inode_size_ok() pass to it the
Duncan posted on Mon, 06 Apr 2015 09:20:12 + as excerpted:
Pavel Volkov posted on Mon, 06 Apr 2015 10:40:03 +0300 as excerpted:
By the way, is there any way to see which options are enabled on a
local filesystem without having to try mounting it with old kernel and
checking dmesg?
On Mon, 6 Apr 2015 07:40:03 AM Pavel Volkov wrote:
On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
That's these, I think:
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA (1ULL 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF(1ULL 6)
so it's definitely -O^extref. I
On Mon, 6 Apr 2015 03:21:18 AM Duncan wrote:
So... for 3.2 compatibility, extref must not be enabled (tho it's now the
default and AFAIK there's no way to actually disable it, only enable, so
an old btrfs-tools would have to be used that doesn't enable it by
default), AND the nodesize must
On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
That's these, I think:
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA (1ULL 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF(1ULL 6)
so it's definitely -O^extref. I don't see where big_metadata comes
from, though. That's not a
On Mon, Mar 30, 2015 at 8:12 PM, Jeff Mahoney je...@suse.com wrote:
The combination of mkfs.btrfs discarding the entire block device and the
old behavior of block groups being retained forever made iterating over
the block groups on disk for FITRIM an easy optimization. If there wasn't
a block
Pavel Volkov posted on Mon, 06 Apr 2015 10:40:03 +0300 as excerpted:
On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
That's these, I think:
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA (1ULL 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF(1ULL 6)
so it's definitely
On Thu, Apr 02, 2015 at 10:17:47AM -0400, Chris Mason wrote:
Hi stable friends,
Can you please backport this one to 3.19.y. It fixes a bug introduced by:
381cf6587f8a8a8e981bc0c18859b51dc756, which was tagged for stable 3.14+
The symptoms of the bug are deadlocks during log reply
On Mon, Apr 06, 2015 at 10:40:03AM +0300, Pavel Volkov wrote:
On Sunday, April 5, 2015 1:04:17 PM MSK, Hugo Mills wrote:
That's these, I think:
#define BTRFS_FEATURE_INCOMPAT_BIG_METADATA (1ULL 5)
#define BTRFS_FEATURE_INCOMPAT_EXTENDED_IREF(1ULL 6)
so it's definitely
Martin,
presumably kernel failed to read SB from disk /dev/sdf5,
bit strange it saw 'Inappropriate ioctl for device',
logically that don't explain.
Curios to know what does 'btrfs fi show -d' say ?
and output of blkid if you could. The situation here
is not same as destroying the SB
Hello!
I have to recover a corrupt btrfs. The size is approx 4.5 TB. The fs became
corrupt by failure of a hardware-raid. The BTRFS was created using the
compress-option.
For the restore-process I made an image, btrfs-progs are version 3.19, kernel
3.19.2-1, 64 bit.
The 0. superblock was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/6/15 5:17 AM, Filipe David Manana wrote:
On Mon, Mar 30, 2015 at 8:12 PM, Jeff Mahoney je...@suse.com
wrote:
The combination of mkfs.btrfs discarding the entire block device
and the old behavior of block groups being retained forever made
On Mon, Apr 6, 2015 at 5:40 AM, Martin deve...@imagmbh.de wrote:
Hello!
I have to recover a corrupt btrfs. The size is approx 4.5 TB. The fs became
corrupt by failure of a hardware-raid.
What raid level? What kind of failure? What is the current raid
status? What was the mkfs.btrfs command
18 matches
Mail list logo
