Steps to reproduce:
# mkfs.btrfs -f /dev/sdb
# mount -t btrfs /dev/sdb /mnt
# btrfs sub create /mnt/dir
# mount -t btrfs /dev/sdb /mnt -o subvol=dir,subvol=dir
It fails with:
mount: mount(2) failed: No such file or directory
Btrfs deal with subvolume mounting in a recursive way,
to avoid
When converting a sparse ext* filesystem, btrfs-convert adds checksum extents
for empty extents, whose disk_bytenr = 0, and this can end up with some weird
problems, one of them is the failure of reading free space cache inode on
mounting converted btrfs.
The fix is simple, just to skip making
On Mon, Nov 24, 2014 at 08:23:25AM +, Holger Hoffstätte wrote:
On Mon, 24 Nov 2014 13:23:05 +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
Would there be room for a compromise with e.g. 128 bits?
For example, Spooky V2 hash is 128 bits and is very fast. It is
2014-11-25 11:30 GMT+01:00 Liu Bo bo.li@oracle.com:
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Holger Hoffstätte
holger.hoffstae...@googlemail.com wrote:
Would there be room for a compromise with e.g. 128 bits?
For example, Spooky
On 2014-11-24 02:46, Duncan wrote
if you were using gmane's web service, that explains things as
weaverd, the process
that does the threading on the web side, was down for some days
Yes, I have used gmane blog. Good to know it is not down anymore.
Back on topic. Even after updating
I am in the middle of replacing /dev/sdb (which is 3TB SATA disk that gives a
few read errors on every scrub) with /dev/sdc2 (a partition on a new 4TB SATA
disk). I am running btrfs-tools version 3.17-1.1 from Debian/Unstable and
Debian kernel 3.16.0-4-amd64. I get the following, the last
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
As
On Tue, Nov 25 2014, Theodore Ts'o ty...@mit.edu wrote:
static int update_time(struct inode *inode, struct timespec *time, int flags)
{
+ struct timespec uptime;
+ unsigned short daycode;
int ret;
if (inode-i_op-update_time) {
@@ -1525,17 +1527,33 @@ static int
On Fri, Nov 14, 2014 at 8:50 AM, Miao Xie mi...@cn.fujitsu.com wrote:
This patchset implement the device scrub/replace function for RAID56,
the
most implementation of the common data is similar to the other RAID
type.
The differentia or difficulty is the parity process. In order to avoid
that
On 11/25/2014 06:33 AM, Theodore Ts'o wrote:
I was concerned about putting them on the dirty inode list because it
would be extra inodes for the writeback threads would have to skip
over and ignore (since they would not be dirty in the inde or data
pages sense).
Another solution would be
On Mon, Nov 24, 2014 at 06:34:30PM +0100, David Sterba wrote:
The btrfs_root_readonly checks in setxattr and removexattr are
unnecessary because they're done through xattr_permisssion. I'll send a
patch to remove them.
Does not work because the security.* and system.* namespaces do not call
On Tue, Nov 25, 2014 at 03:58:01PM +0100, Rasmus Villemoes wrote:
I think days_since_boot was a lot clearer than daycode. In any case,
please make the comment and the code consistent.
Yeah, I was going back and forth between days since the epoch and days
since boot, but found it was more
Add the code for the btrfs chunk list command. The code iterates
through the chunk, grouping these by chunk type (data, metadata,
system) and chunk profiles (linear, dup, raid1, radi5, raid10,
raid6..); then it displays the devices belong each group.
If a device is missing, it is marked as
This patch adds the 'btrfs chunk' groups command.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
Makefile | 2 +-
btrfs.c| 1 +
commands.h | 2 ++
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 4cae30c..1744f9c 100644
--- a/Makefile
+++
This is a revamp of a my previous patches set[1]. After more than
year of attempts these patches were never merged, so I tried to
simplify them and to change a bit the focus. The previous patches set
had the focus to the disk usage.
The aim of these patches now is to show the chunks distribution
Add btrfs-chunk(8) man page, and update btrfs(8) man page.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
Documentation/Makefile| 1 +
Documentation/btrfs-chunk.txt | 58 +++
Documentation/btrfs.txt | 5
3 files changed, 64
Move group_type_str() and group_profile_str() functions to the
util.c file, because these are now used also by the command
'btrfs chunk list'.
Signed-off-by: Goffredo Baroncelli kreij...@inwind.it
---
cmds-filesystem.c | 43 ---
utils.c | 43
On Tue, Nov 25, 2014 at 12:34:29AM -0500, Theodore Ts'o wrote:
In preparation for adding support for the lazytime mount option, we
need to be able to separate out the update_time() and write_time()
inode operations. Currently, only btrfs and xfs uses update_time().
We needed to preserve
On Tue, Nov 25, 2014 at 12:34:34AM -0500, Theodore Ts'o wrote:
The only reason btrfs cloned code from the VFS layer was so it could
add a check to see if a subvolume is read-ony. Instead of doing that,
let's add a new inode operation which allows a file system to return
an error if the inode
On Tue, Nov 25, 2014 at 04:57:21PM +0100, Goffredo Baroncelli wrote:
This is a revamp of a my previous patches set[1]. After more than
year of attempts these patches were never merged, so I tried to
simplify them and to change a bit the focus. The previous patches set
had the focus to the disk
Hi Goffredo,
Am Dienstag, 25. November 2014, 16:57:21 schrieb Goffredo Baroncelli:
This is a revamp of a my previous patches set[1]. After more than
year of attempts these patches were never merged, so I tried to
simplify them and to change a bit the focus. The previous patches set
had the
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or otherwise). It's also
not a particularly common use case, while making an LV snapshot of a
filesystem is a typical use
On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c for
performance purposes.
As crc32c is sort of weak due to its hash collision issue, we need a stronger
In attempt to get more information, I have commented out
BUG_ON(rec-is_root) in cmds-check.c to let btrfsck check my file system
without failing on this assertion. Below you can see the output. I would
appreciate any help or ideas...
# btrfsck /dev/sdb1 # Full log can be downloaded
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
On Tue, Nov 25, 2014 at 04:51:41PM +0100, David Sterba wrote:
Does not work because the security.* and system.* namespaces do not call
the permission() hook, so no patch. However, if the proposed
inode_is_readonly callback is merged, we can replace the btrfs-specific
checks with is_readonly
On 11/25/2014 05:13 PM, David Sterba wrote:
On Tue, Nov 25, 2014 at 04:57:21PM +0100, Goffredo Baroncelli wrote:
This is a revamp of a my previous patches set[1]. After more than
year of attempts these patches were never merged, so I tried to
simplify them and to change a bit the focus. The
On 11/25/2014 05:08 PM, Martin Steigerwald wrote:
Hi Goffredo,
Am Dienstag, 25. November 2014, 16:57:21 schrieb Goffredo Baroncelli:
This is a revamp of a my previous patches set[1]. After more than
year of attempts these patches were never merged, so I tried to
simplify them and to change
On Mon 24-11-14 23:33:35, Ted Tso wrote:
On Tue, Nov 25, 2014 at 12:52:39PM +1100, Dave Chinner wrote:
Eviction is too late for this. I'm pretty sure that it won't get
this far as iput_final() should catch the I_DIRTY_TIME in the !drop
case via write_inode_now().
Actually, the tracepoint
On Mon 24-11-14 23:33:35, Ted Tso wrote:
On Tue, Nov 25, 2014 at 12:52:39PM +1100, Dave Chinner wrote:
+static void flush_sb_dirty_time(struct super_block *sb)
+{
...
+}
This just seems wrong to me, not to mention extremely expensive when we have
millions of cached inodes on
On Fri 21-11-14 14:59:23, Ted Tso wrote:
Guarantee that the on-disk timestamps will be no more than 24 hours
stale.
Hum, how about reusing i_dirtied_when for this. Using that field even
makes a good sence to me...
Honza
On Fri 21-11-14 14:59:24, Ted Tso wrote:
Add an optimization for the MS_LAZYTIME mount option so that we will
opportunistically write out any inodes with the I_DIRTY_TIME flag set
in a particular inode table block when we need to update some inode in
that inode table block anyway.
Also add
On Tue, Nov 25, 2014 at 04:20:11PM +0800, Wang Shilong wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sdb
# mount -t btrfs /dev/sdb /mnt
# btrfs sub create /mnt/dir
# mount -t btrfs /dev/sdb /mnt -o subvol=dir,subvol=dir
It fails with:
mount: mount(2) failed: No such file or
On Tue, Nov 25, 2014 at 06:10:29PM +0100, Goffredo Baroncelli wrote:
Can the chunk list also display the usage inside the chunks?
Unfortunately not. I don't know how it would be possible to get this info.
It takes some more parsing of the fs structures, doable via the
SEARCH_TREE ioctl. I have
On Tue, Nov 25, 2014 at 06:19:27PM +0100, Jan Kara wrote:
Actually, I'd also prefer to do the writing from iput_final(). My main
reason is that shrinker starts behaving very differently when you put
inodes with I_DIRTY_TIME to the LRU. See inode_lru_isolate() and in
particular:
/*
Hi,
so started reviewing the patches for inclusion in the 3.18 branch and
found a few things that I've fixed locally, this is just FYI.
On Sun, Nov 09, 2014 at 11:16:55PM +0100, Silvio Fricke wrote:
Signed-off-by: Silvio Fricke silvio.fri...@gmail.com
---
task-util.c | 121
Fixed locally, no need to resend the patch. JFYI the changes I made
On Sun, Nov 09, 2014 at 11:16:56PM +0100, Silvio Fricke wrote:
---
Documentation/btrfs-convert.txt | 2 ++
Makefile| 6 ++--
btrfs-convert.c | 64
On Mon, Nov 24, 2014 at 05:06:59PM +0800, Qu Wenruo wrote:
Introduce the new 'lost+found' dir and related infrastructure to create it
in btrfs-progs.
[BUG]
With the new infrastructure, fix a bug that some people reported in both
kernel BZ and maillist, which there is some files' nlink is 1
Signed-off-by: David Sterba dste...@suse.cz
---
btrfs-list.c | 4 ++--
qgroup.c | 2 +-
send-utils.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index b6b84935109d..50edcf493869 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1711,7
Dear Sir
Did your website get hit by Google Penguin update on October 17th 2014? What
basically is Google Penguin Update? It is actually a code name for Google
algorithm which aims at decreasing your websites search engine rankings that
violate Googles guidelines by using black hat SEO
On Tue, Nov 25, 2014 at 06:30:40PM +0100, Jan Kara wrote:
This would be possible and as Boaz says, it might be possible to reuse
the same list_head in the inode for this. Getting rid of the full scan of
all superblock inodes would be nice (as the scan gets really expensive for
large numbers
On 2014-11-25 17:47, David Sterba wrote:
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo bo.li@oracle.com wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
On Tue 25-11-14 12:57:16, Ted Tso wrote:
On Tue, Nov 25, 2014 at 06:19:27PM +0100, Jan Kara wrote:
Actually, I'd also prefer to do the writing from iput_final(). My main
reason is that shrinker starts behaving very differently when you put
inodes with I_DIRTY_TIME to the LRU. See
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or otherwise). It's also
not a particularly common
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 7:05 PM, Chris Murphy wrote:
I'm not a hard drive engineer, so I can't argue either point. But
consumer drives clearly do behave this way. On Linux, the kernel's
default 30 second command timer eventually results in what look
like
On 11/25/2014 09:29 PM, Zygo Blaxell wrote:
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and because it's always
the lowest layer it can ignore LVs (snapshot or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/19/2014 6:59 PM, Duncan wrote:
It's not physical spinup, but electronic device-ready. It happens
on SSDs too and they don't have anything to spinup.
If you have an SSD that isn't handling IO within 5 seconds or so of
power on, it is badly
On Tue, Nov 25, 2014 at 10:59:53PM +0100, Goffredo Baroncelli wrote:
On 11/25/2014 09:29 PM, Zygo Blaxell wrote:
On Tue, Nov 25, 2014 at 05:34:15PM +0100, Goffredo Baroncelli wrote:
On 11/23/2014 01:19 AM, Zygo Blaxell wrote:
[...]
md-raid works as long as you specify the devices, and
I'm still seeing this when running balance with 3.18-rc6:
[95334.066898] BTRFS info (device sdd1): relocating block group
6468350771200 flags 17
[95344.384279] BTRFS info (device sdd1): found 5371 extents
[95373.555640] BTRFS (device sdd1): parent transid verify failed on
5568935395328 wanted
What happens when all btrfs LVs are unmounted, and you lvchange -an
the LVs (the pair) you do not want mounted; and then btrfs dev scan;
and then mount one of the devices? It should only find the matching LV
because the others are deactivated. I know this isn't ideal, but it's
better than
On Tue, Nov 25, 2014 at 2:34 PM, Phillip Susi ps...@ubuntu.com wrote:
I have seen plenty of error logs of people with drives that do
properly give up and return an error instead of timing out so I get
the feeling that most drives are properly behaved. Is there a
particular make/model of
On Tue, Nov 25, 2014 at 2:30 AM, Liu Bo bo.li@oracle.com wrote:
On Mon, Nov 24, 2014 at 11:34:46AM -0800, John Williams wrote:
For example, Spooky V2 hash is 128 bits and is very fast. It is
noncryptographic, but it is more than adequate for data checksums.
On Mon, Nov 24, 2014 at 11:45:08PM -0500, Theodore Ts'o wrote:
On Tue, Nov 25, 2014 at 12:53:32PM +1100, Dave Chinner wrote:
On Fri, Nov 21, 2014 at 02:59:23PM -0500, Theodore Ts'o wrote:
Guarantee that the on-disk timestamps will be no more than 24 hours
stale.
Signed-off-by:
On Mon, Nov 24, 2014 at 11:33:35PM -0500, Theodore Ts'o wrote:
On Tue, Nov 25, 2014 at 12:52:39PM +1100, Dave Chinner wrote:
+static void flush_sb_dirty_time(struct super_block *sb)
+{
...
+}
This just seems wrong to me, not to mention extremely expensive when we have
millions
Original Message
Subject: Re: [PATCH 0/6] btrfs-progs: New 'lost+found' infrastructrue with
From: David Sterba dste...@suse.cz
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年11月26日 02:32
On Mon, Nov 24, 2014 at 05:06:59PM +0800, Qu Wenruo wrote:
Introduce the new
Add btrfs_unlink() and btrfs_add_link() functions in inode.c,
for the incoming btrfs_mkdir() and later inode operations functions.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Do dir name conflicting check before adding inode_backref or
dir_item/index.
---
Makefile
With the previous btrfs inode operations patches, now we can use
btrfs_mkdir() to create the 'lost+found' dir to do some data salvage in
btrfsck.
This patch along with previous ones will make data salvage easier.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Fix a bug
On Tue, Nov 25, 2014 at 04:20:11PM +0800, Wang Shilong wrote:
Steps to reproduce:
# mkfs.btrfs -f /dev/sdb
# mount -t btrfs /dev/sdb /mnt
# btrfs sub create /mnt/dir
# mount -t btrfs /dev/sdb /mnt -o subvol=dir,subvol=dir
It fails with:
mount: mount(2) failed: No such file or
On Tue, Nov 25, 2014 at 6:13 PM, Chris Murphy li...@colorremedies.com wrote:
A few years ago companies including Western Digital started shipping
large cheap drives, think of the green drives. These had very high
TLER (Time Limited Error Recovery) settings, a.k.a. SCT ERC. Later
they
Add btrfs_unlink() and btrfs_add_link() functions in inode.c,
for the incoming btrfs_mkdir() and later inode operations functions.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Do dir name conflicting check before adding inode_backref or
dir_item/index.
---
Makefile
With the previous btrfs inode operations patches, now we can use
btrfs_mkdir() to create the 'lost+found' dir to do some data salvage in
btrfsck.
This patch along with previous ones will make data salvage easier.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
---
Changlog:
v2:
Fix a bug
Hi Daniel,
With your btrfs-image dump, I tested with my patchset sent to maillist,
my patchset succeeds fixing the image.
You can get the patchset and then apply it on 3.17.2, and --repair
should fix it.
The file with nlink error will be moved to 'lost+found' dir.
Although the best fixing
The @search_cache_extent() only returns the next cache_extent or NULL,
it will never return the previous cache_extent.
So just remove the dead condition for previous cache_extent handle.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
volumes.c | 2 +-
1 file changed, 1 insertion(+), 1
Run fstests: btrfs/012 will fail with message:
unable to do rollback
It is because the rollback function checks sequentially each piece of space
to map to a certain block group. If some piece doesn't, rollback refuses to
continue.
After kernel commit:
commit
-20141125
Wang Shilong (3):
Btrfs-progs: fsck: deal with snapshot one by one when rebuilding
extent tree
Btrfs-progs: fsck: add ability to rebuild extent tree with snapshots
Btrfs-progs, fsck: move root items repair after root rebuilding
cmds-check.c | 412
From: Wang Shilong wangsl.f...@cn.fujitsu.com
This patch makes us to rebuild a really corrupt extent tree with snapshots.
To implement this, we have to verify whether a block is FULL BACKREF.
This idea come from Josef Bacik:
1) We walk down the original tree, every eb we encounter has
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Previously, we deal with node block firstly and then leaf block which can
maximize readahead. However, to rebuild extent tree, we need deal with snapshot
one by one.
This patch makes us deal with snapshot one by one if we need rebuild extent
tree
If some critical roots are corrupt, reapr_root_items() will fail,
this is detected by fsck_tests.sh's extent rebuilding tests.
Signed-off-by: Wang Shilong wangshilong1...@gmail.com
---
cmds-check.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff
If some critical roots are corrupt, reapr_root_items() will fail,
this is detected by fsck_tests.sh's extent rebuilding tests.
Signed-off-by: Wang Shilong wangshilong1...@gmail.com
---
cmds-check.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Previously, we deal with node block firstly and then leaf block which can
maximize readahead. However, to rebuild extent tree, we need deal with snapshot
one by one.
This patch makes us deal with snapshot one by one if we need rebuild extent
tree
-20141125
Wang Shilong (3):
Btrfs-progs: fsck: deal with snapshot one by one when rebuilding
extent tree
Btrfs-progs: fsck: add ability to rebuild extent tree with snapshots
Btrfs-progs, fsck: move root items repair after root rebuilding
cmds-check.c | 412
From: Wang Shilong wangsl.f...@cn.fujitsu.com
This patch makes us to rebuild a really corrupt extent tree with snapshots.
To implement this, we have to verify whether a block is FULL BACKREF.
This idea come from Josef Bacik:
1) We walk down the original tree, every eb we encounter has
,
root items also won't succeed.
patches are based on David's integration-20141125
Wang Shilong (3):
Btrfs-progs: fsck: deal with snapshot one by one when rebuilding
extent tree
Btrfs-progs: fsck: add ability to rebuild extent tree with snapshots
Btrfs-progs, fsck: move root items
Alright, I'll just have to understand how to build btrfs-progs now,
since I'm currently just using the packages from the Fedora repo.
Thanks for all the help and time spent so far,
Daniel
On Wed, Nov 26, 2014 at 12:41 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Hi Daniel,
With your
Goffredo Baroncelli posted on Tue, 25 Nov 2014 22:59:53 +0100 as
excerpted:
However I still doesn't understood why you want btrfs-w/multiple disk
over LVM ?
While I'm not an LVM person here, and he already replied with essentially
the same point, I think it's worth repeating...
Btrfs'
On Tue, Nov 25, 2014 at 7:11 PM, Zygo Blaxell zblax...@furryterror.org wrote:
On Tue, Nov 25, 2014 at 03:46:32PM -0700, Chris Murphy wrote:
What happens when all btrfs LVs are unmounted, and you lvchange -an
the LVs (the pair) you do not want mounted; and then btrfs dev scan;
and then mount
77 matches
Mail list logo
