Martin wrote (ao):
Are there any format/mount parameters that should be set for using
btrfs on SSDs (other than the ssd mount option)?
If possible, format the whole device, do not partition the ssd. This
will guarantee proper allignment.
The kernel will detect the ssd, and apply the ssd mount
We've forgotten to clear extent states in pinned tree, which will results in
space counter mismatch and memory leak:
WARNING: at fs/btrfs/extent-tree.c:7537 btrfs_free_block_groups+0x1f3/0x2e0
[btrfs]()
...
space_info 2 has 8380416 free, is not full
space_info total=12582912, used=4096,
From: Miao Xie mi...@cn.fujitsu.com
the items of the delayed inodes were forgotten to be freed, this patch
fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/delayed-inode.c | 18 ++
fs/btrfs/delayed-inode.h |3 +++
fs/btrfs/disk-io.c |6 ++
3
Since we have two trees for recording pinned extents, we need to go through
both of them to make sure that we've done everything clean.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/disk-io.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
Greetings everybody,
I have been studying some of the btrfs code and the developer
documentation on the wiki. My primary interest at this point, is to be
able to search within fs tree of a btrfs subvolume, which was created
as a snapshot of another subvolume. For that I have been using the
On Fri, May 18, 2012 at 02:21:59PM +0300, Alex Lyakas wrote:
Greetings everybody,
I have been studying some of the btrfs code and the developer
documentation on the wiki. My primary interest at this point, is to be
able to search within fs tree of a btrfs subvolume, which was created
as a
On Wed, May 16, 2012 at 06:50:47PM +0200, Stefan Behrens wrote:
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -823,6 +823,26 @@ struct btrfs_csum_item {
u8 csum;
} __attribute__ ((__packed__));
+struct btrfs_device_stats_item {
+ /*
+ * grow this item struct at the
I have sinned!
I had a production filesystem without a replica - which is bonked :(
Running restore ( i have tried Debian's btrfs-tools; master and
dangerdonteveruse branches version ) on kernels 3.2 and 3.3 I
consistently get this error message, and I would like suggestions as
to how i might
On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb, int
*flags, char *data)
/* pause restriper - we want to resume on remount to r/w */
On Thu, May 17, 2012 at 08:08:08PM +0800, Liu Bo wrote:
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1303,6 +1303,13 @@ static noinline int btrfs_ioctl_resize(struct
btrfs_root *root,
ret = -EINVAL;
goto out_free;
}
+ if (device-fs_devices
Thank you, Hugo, for the detailed explanation. I am now able to find
the CHUNK_ITEMs and to successfully locate the file data on disk.
Can you maybe address several follow-up questions I have?
# When looking for CHUNK_ITEMs, should I check that their
btrfs_chunk::type==BTRFS_BLOCK_GROUP_DATA (and
On Fri, May 18, 2012 at 04:32:09PM +0300, Alex Lyakas wrote:
Thank you, Hugo, for the detailed explanation. I am now able to find
the CHUNK_ITEMs and to successfully locate the file data on disk.
Can you maybe address several follow-up questions I have?
# When looking for CHUNK_ITEMs, should
On Fri, May 18, 2012 at 6:04 AM, Lars Bahner
bah...@onlinebackupcompany.com wrote:
I have sinned!
I had a production filesystem without a replica - which is bonked :(
Grr...
Running restore ( i have tried Debian's btrfs-tools; master and
dangerdonteveruse branches version ) on kernels 3.2
I would not buy anything else
than intel. I have about 26 of them for years now (both in servers and
workstations, several series), and never had an issue. Two of my
colleagues have OCZ, and both had to RMA them.
I guess it boils down wether you want intel also to rule the SSD
market in the
On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote:
I would not buy anything else
than intel. I have about 26 of them for years now (both in servers and
workstations, several series), and never had an issue. Two of my
colleagues have OCZ, and both had to RMA them.
I guess
On Fri, 2012-05-18 at 17:32 +0200, Tomasz Torcz wrote:
On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote:
I would not buy anything else
than intel. I have about 26 of them for years now (both in servers and
workstations, several series), and never had an issue. Two of my
- if a non-RAID SAS card is used, does it matter which card is chosen?
Does btrfs work equally well with all of them?
If you're using btrfs RAID, you need a HBA, not a RAID card. If the RAID
card can work as a HBA (usually labelled as JBOD mode) then you're good to
go.
For example, HP
On Mon, May 14, 2012 at 10:11:01AM -0700, Brendan Smithyman wrote:
The disks that *are* still showing the subdirectory creation issue
were both converted from ext4 (using old tools). So perhaps that's a
direction to explore.
Yeah, thanks for the hint.
david
--
To unsubscribe from this list:
Hi Josef,
there was one line before the bug.
[ 995.725105] couldn't find orphan item for 524
Am 18.05.2012 16:48, schrieb Josef Bacik:
Ok hopefully this will print something out that makes sense. Thanks,
-martin
[ 241.754693] Btrfs loaded
[ 241.755148] device fsid
When we write out the free space cache we will write out everything that is
in our in memory tree, and then we will just walk the pinned extents tree
and write anything we see there. The problem with this is that during
normal operations the pinned extents will be merged back into the free space
Hello.
2012/5/18 Liu Bo liubo2...@cn.fujitsu.com
On 05/18/2012 12:10 AM, Sergey E. Kolesnikov wrote:
Could you please show some logs about the corrpution?
Ugh. Sorry, but logs got corrupted too :-(
Today I've tested 3.4-rc7 kernel and everything seems to be fine.
May be fix mentioned by
Hi Josef,
now I get
[ 2081.142669] couldn't find orphan item for 2039, nlink 1, root 269,
root being deleted no
-martin
Am 18.05.2012 21:01, schrieb Josef Bacik:
*sigh* ok try this, hopefully it will point me in the right direction. Thanks,
[ 126.389847] Btrfs loaded
[ 126.390284]
Probably the larger filesystem I will ever see. Tryed 8 Exabytes but it failed.
[root@CentOS6-A:/root] # df
Filesystem1K-blocks Used Available Use%
Mounted
/dev/mapper/vg01-root 17915884 11533392 5513572 68% /
/dev/sda1
Dan Williams wrote:
The consensus from LSF was that bcache need not invent a new interface
when md and dm can both do the job. As mentioned in patch 7 this series
aims to be a minimal conversion. Other refactoring items like
deprecating register_lock for mddev-reconfig_mutex are deferred.
24 matches
Mail list logo
