On Tue, Nov 25, 2014 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> From my perspective, however, btrfs is simply incompatible with lvm
> snapshots, because the basic assumptions are incompatible. Btrfs assumes
> UUIDs will be exactly what they say on the label, /unique/, while lvm's
> snapsho
On Tue, Nov 25, 2014 at 7:11 PM, Zygo Blaxell 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 one of the devices?
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' check
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 wrote:
> Hi Daniel,
>
> With your btrfs-image dump, I tested wi
ould be at first, because if root(extent root eg) corrupted,
> 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
> B
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
---
cmds-check.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/cmds-check.c b/cmds-c
From: Wang Shilong
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 otherwise we drop into previou
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 repair after root rebuil
From: Wang Shilong
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
btrfs_header_owner(eb) == root->obje
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
---
cmds-check.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/cmds-check.c b/cmds-c
From: Wang Shilong
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
btrfs_header_owner(eb) == root->obje
From: Wang Shilong
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 otherwise we drop into previou
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 repair after root rebuil
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 47ab2a6c689913db23cca
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
---
volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
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 s
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
---
Changlog:
v2:
Fix a bug that returns the parent ino
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
---
Changlog:
v2:
Do dir name conflicting check before adding inode_backref or
dir_item/index.
---
Makefile | 2 +-
cmds-check.c
On Tue, Nov 25, 2014 at 6:13 PM, Chris Murphy 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 completely took out the abi
>
> 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
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
---
Changlog:
v2:
Fix a bug that returns the parent ino
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
---
Changlog:
v2:
Do dir name conflicting check before adding inode_backref or
dir_item/index.
---
Makefile | 2 +-
cmds-check.c
Original Message
Subject: Re: [PATCH 0/6] btrfs-progs: New 'lost+found' infrastructrue with
From: David Sterba
To: Qu Wenruo
Date: 2014年11月26日 02:32
On Mon, Nov 24, 2014 at 05:06:59PM +0800, Qu Wenruo wrote:
Introduce the new 'lost+found' dir and related infrastructure to cr
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 ha
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.
> > >
> > > Signe
On Tue, Nov 25, 2014 at 2:30 AM, Liu Bo 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.
>>
>> http://burtleburtle.net/bob/hash/spooky.htm
On Tue, Nov 25, 2014 at 2:34 PM, Phillip Susi 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 drive that is kno
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 corruptio
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
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 devi
-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 b
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 o
-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
> li
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
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 in
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 wrote:
>>> This brings a strong-but-slow checksum algorithm, sha256.
>>>
>>> Actually btrfs used sha256 at the early time, but then moved to
>>> crc3
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 numbe
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 techniq
Signed-off-by: David Sterba
---
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 +1711,7 @@ int btr
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
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
> ++
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
> ---
> task-util.c | 121
>
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:
>
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 ha
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 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
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
> Signe
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 cac
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 tr
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
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.
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 Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
> On Mon, Nov 24, 2014 at 12:23 AM, 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.
> >
> > A
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 her
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 stron
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
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 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 d
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 ino
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
Add btrfs-chunk(8) man page, and update btrfs(8) man page.
Signed-off-by: Goffredo Baroncelli
---
Documentation/Makefile| 1 +
Documentation/btrfs-chunk.txt | 58 +++
Documentation/btrfs.txt | 5
3 files changed, 64 insertions(+)
crea
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
---
cmds-filesystem.c | 43 ---
utils.c | 43 +++
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
am
This patch adds the 'btrfs chunk' groups command.
Signed-off-by: Goffredo Baroncelli
---
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
+++ b/Makefile
@@ -15,7
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 'Missing
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 ef
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 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
On Fri, Nov 14, 2014 at 8:50 AM, Miao Xie 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 problem the data that
On Tue, Nov 25 2014, Theodore Ts'o 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 update_
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
> On Mon, Nov 24, 2014 at 12:23 AM, 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
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 sect
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
2014-11-25 11:30 GMT+01:00 Liu Bo :
> 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
>> 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
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
> 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
> noncryptographic, but it is more than
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.
> >
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 che
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 loo
78 matches
Mail list logo
