Signed-off-by: Davide Italiano
---
fs/btrfs/inode.c | 190 ++-
1 file changed, 189 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index d2e732d..49b0867 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -889
This is an attempt to implement RENAME_EXCHANGE in btrfs.
It survived basic testing and I think it's ready for others' feedback.
I'll stress test {and, or} rewrite it depending on people's comments.
Davide Italiano (1):
Btrfs: RENAME_EXCHANGE semantic for renameat2()
fs/btrfs/inode.c | 190 +++
On Wed, Apr 01, 2015 at 01:22:42PM +0200, David Sterba wrote:
> On Wed, Apr 01, 2015 at 12:03:28AM -0700, Omar Sandoval wrote:
> > --- a/fs/btrfs/super.c
> > +++ b/fs/btrfs/super.c
> > @@ -1024,6 +1024,10 @@ static int btrfs_show_options(struct seq_file *seq,
> > struct dentry *dentry)
> > str
Whenever I have these boot problems, I'm noticing that sometimes the
device, /dev/sda5, is showing up with lsblk (libblkid) as
/dev/block/8:5 while everything else (not-Btrfs) on that device shows
up as /dev/sdaX. Does anyone know what that might mean?
Chris Murphy
--
To unsubscribe from this lis
Before previous patch, btrfs-convert will result fsck complain if there
is any regular file extent in newly converted btrfs.
Add test case for it.
Signed-off-by: Qu Wenruo
---
tests/convert-tests.sh | 85 --
1 file changed, 55 insertions(+), 30 de
Before this patch, ext*_image is always set NODATACSUM inode flag.
However btrfs-convert will set normal file with DATACUSM flag by
default, and generate checksum for regular file extent.
Now, a regular file extent is shared by a btrfs file inode with DATACSUM
and ext*_image with NODATACSUM, and i
On Wed, Apr 01, 2015 at 03:01:07PM -0400, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 4/1/15 2:44 PM, Brian Foster wrote:
> > On Mon, Mar 30, 2015 at 03:11:06PM -0400, Jeff Mahoney wrote:
> >> This tests tests four conditions where discard can potentially
> >> not
I am attempting to see if this message goes through. My first one got
returned as I didn't know gmail defaulted to HTML.
My second and third never seemed distributed.
Are attachments allowed?
According to this,
https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list, they are,
but other thin
Related bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=68411
https://bugzilla.redhat.com/show_bug.cgi?id=1037963
The RHBZ one also mentioned the shadow file.
Anyway, it seems to be a somewhat known problem, but it's just not
known yet what causes it.
Chris Murphy
--
To unsubscribe from this
On Wed, Apr 1, 2015 at 1:23 PM, Martin Langhoff
wrote:
> On Wed, Apr 1, 2015 at 2:54 PM, Chris Murphy wrote:
>> Re-run the btrfs check. The error is still there even after a --repair.
>
> Bingo! You are right the error persists.
>
> It has no effect on my use of the system right now. Is anyone
>
On Wed, Apr 1, 2015 at 3:58 PM, Guenter Roeck
wrote:
On 04/01/2015 12:28 PM, Chris Mason wrote:
On Sun, Mar 29, 2015 at 11:24 PM, Guenter Roeck
wrote:
On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
Building alpha:allmodconfig fails with
fs/btrfs/inode.c: In function 'check
On 04/01/2015 12:28 PM, Chris Mason wrote:
On Sun, Mar 29, 2015 at 11:24 PM, Guenter Roeck wrote:
On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
Building alpha:allmodconfig fails with
fs/btrfs/inode.c: In function 'check_direct_Excellent idea. Done,IO':
fs/btrfs/inode.c:805
On Wed, Apr 1, 2015 at 2:50 AM, Anand Jain wrote:
>
> Eric found something like this and has a fix with in the email.
> Sub: "I think "btrfs: fix leak of path in btrfs_find_item" broke stable
> trees ..."
>
I don't mind trying this patch if the maintainers recommend it. I'm
still getting panics
On Sun, Mar 29, 2015 at 11:24 PM, Guenter Roeck
wrote:
On Fri, Mar 13, 2015 at 01:58:46AM -0700, Guenter Roeck wrote:
Building alpha:allmodconfig fails with
fs/btrfs/inode.c: In function 'check_direct_IO':
fs/btrfs/inode.c:8050:2: error: implicit declaration of function
'iov_iter_alignment
On Wed, Apr 1, 2015 at 2:54 PM, Chris Murphy wrote:
> Re-run the btrfs check. The error is still there even after a --repair.
Bingo! You are right the error persists.
It has no effect on my use of the system right now. Is anyone
interested in debugging this further?
cheers,
martin
--
marti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/1/15 2:44 PM, Brian Foster wrote:
> On Mon, Mar 30, 2015 at 03:11:06PM -0400, Jeff Mahoney wrote:
>> This tests tests four conditions where discard can potentially
>> not discard unused extents completely.
>>
>> We test, with -o discard and with
On Wed, Apr 1, 2015 at 12:29 PM, Martin Langhoff
wrote:
> On Wed, Apr 1, 2015 at 2:20 PM, Chris Murphy wrote:
>> That won't fix it. Once errors 400 appears, at this point you have to
>> replace the affected file.
>
> Interesting.
>
> Right now I am booting without problems. I have no evidence of
On Mon, Mar 30, 2015 at 03:11:06PM -0400, Jeff Mahoney wrote:
> This tests tests four conditions where discard can potentially not
> discard unused extents completely.
>
> We test, with -o discard and with fstrim, scenarios of removing many
> relatively small files and removing several large files
On Wed, Apr 1, 2015 at 2:20 PM, Chris Murphy wrote:
> That won't fix it. Once errors 400 appears, at this point you have to
> replace the affected file.
Interesting.
Right now I am booting without problems. I have no evidence of
continued problems. What would I do to check whether I see an error
On Wed, Apr 1, 2015 at 12:16 PM, Martin Langhoff
wrote:
> On Wed, Apr 1, 2015 at 2:04 PM, Chris Murphy wrote:
>> When I had this same btrfs check error, it was the exact inode number
>> and same /etc/shadow file. I didn't diff the two shadow files, but I
>
> That's too bizarre for words. Two folk
On Wed, Apr 1, 2015 at 2:04 PM, Chris Murphy wrote:
> When I had this same btrfs check error, it was the exact inode number
> and same /etc/shadow file. I didn't diff the two shadow files, but I
That's too bizarre for words. Two folks, on two different systems,
getting btrfs problems on similar k
On Wed, Apr 1, 2015 at 11:26 AM, Martin Langhoff
wrote:
> On Wed, Apr 1, 2015 at 1:03 PM, Chris Murphy wrote:
>> mount /dev/sda6 /mnt
>> btrfs inspect-internal inode-resolve 39841 /mnt
>
> on the booted system...
> # uname -a
> Linux tp-martin.remote-learner.net 3.18.9-200.fc21.x86_64 #1 SMP Mon
Anand,
Thanks for picking up.
The devid option sounds good.
Thanks,
Martin
On 01/04/15 14:15, Anand Jain wrote:
>
>
> Looks like an option to use devid to delete a device would
> have mitigated the issue. Also the error reported is no
> where near the reality. Will fix them.
>
> Than
On Wed, Apr 1, 2015 at 1:03 PM, Chris Murphy wrote:
> mount /dev/sda6 /mnt
> btrfs inspect-internal inode-resolve 39841 /mnt
on the booted system...
# uname -a
Linux tp-martin.remote-learner.net 3.18.9-200.fc21.x86_64 #1 SMP Mon
Mar 9 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# btrfs inspe
On Wed, Apr 1, 2015 at 10:15 AM, Martin Langhoff
wrote:
> On Wed, Apr 1, 2015 at 11:42 AM, Martin Langhoff
> wrote:
>> See below. Perhaps the newer kernel (in latest F21) has regressed in
>> handling some kinds of errors during mount, or the dracut/systemd
>> mounting process is less resilient th
On Wed, Apr 1, 2015 at 9:42 AM, Martin Langhoff
wrote:
# mount /dev/sda6 /mysysroot
>
> Apr 01 11:26:51 localhost kernel: BTRFS info (device sda6): disk space
> caching is enabled
> Apr 01 11:26:56 localhost kernel: BTRFS: checking UUID tree
> Apr 01 11:26:56 localhost kernel: SELinux: initialized
On Wed, Apr 1, 2015 at 12:15 PM, Martin Langhoff
wrote:
> Will try to capture some info from a dracut breakpoint (I'll try
> mount). At this point this really looks like a regression.
After a couple alternating boots, the problem vanished :-/:
- 3.18.7-200.fc21 - success
- 3.18.9-200.fc21 - t
On Wed, Apr 1, 2015 at 11:42 AM, Martin Langhoff
wrote:
> See below. Perhaps the newer kernel (in latest F21) has regressed in
> handling some kinds of errors during mount, or the dracut/systemd
> mounting process is less resilient than mounting under a fully booted
> system?
This is getting even
On Tue, Mar 31, 2015 at 4:09 PM, Chris Murphy wrote:
>>A failure of the
>> HDD cannot be ruled out, low power conditions, cheap consumer part...
>
> Well you have to rule that out before anyone on this list can really
> help. Try booting Fedora 21 install media, and using smartctl -x on
> the driv
Hi Chris, list,
thanks for your debugging ideas so far. Now this gets interesting. I
booted off a LiveUSB disk, and it just mounted sysroot. WTH?
See below. Perhaps the newer kernel (in latest F21) has regressed in
handling some kinds of errors during mount, or the dracut/systemd
mounting process
Hi, Andy,
On Wed, Apr 01, 2015 at 03:11:14PM +, Andy Smith wrote:
> I have a 6 device RAID-1 filesystem:
[snip tale of a filesystem with out of data data on one copy of the RAID]
> I have now got a new enclosure and put this system back together
> with all six devices. I was not expecting
Hello,
I have a 6 device RAID-1 filesystem:
$ sudo btrfs fi df /srv/tank
Data, RAID1: total=1.24TiB, used=1.24TiB
System, RAID1: total=32.00MiB, used=184.00KiB
Metadata, RAID1: total=3.00GiB, used=1.65GiB
unknown, single: total=512.00MiB, used=0.00
$ sudo btrfs fi sh /srv/tank
Label: 'tank' uuid
On Tue, Mar 24, 2015 at 6:23 PM, Sophie wrote:
On 24/03/15 17:34, Chris Mason wrote:
On Tue, Mar 24, 2015 at 9:43 AM, Sophie Dexter
wrote:
On 20/03/2015 15:19, Sophie Dexter wrote:
I'm given to understand that this is the right place to report a
btrfs
problem, I apologise if not :-(
Looks like an option to use devid to delete a device would
have mitigated the issue. Also the error reported is no
where near the reality. Will fix them.
Thanks for reporting.
Anand
On 04/01/2015 06:54 PM, Martin wrote:
On 01/04/15 08:06, Anand Jain wrote:
btrfs device delete /dev/s
On Wed, Apr 01, 2015 at 12:42:04PM +, Wang, Zhiye wrote:
> Hello,
> I have some files which I hope their on-disk data can be on fixed
> location of disk. My understanding is that defragmentation operation
> can potentially move data blocks of a file.
> So, can I avoid certain file being defra
Hello,
I have some files which I hope their on-disk data can be on fixed location of
disk. My understanding is that defragmentation operation can potentially move
data blocks of a file.
So, can I avoid certain file being defragmented in btrfs?
Thanks
Mike
On Wed, Apr 01, 2015 at 12:03:28AM -0700, Omar Sandoval wrote:
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -1024,6 +1024,10 @@ static int btrfs_show_options(struct seq_file *seq,
> struct dentry *dentry)
> struct btrfs_root *root = info->tree_root;
> char *compress_type;
>
On 01/04/15 08:06, Anand Jain wrote:
>
btrfs device delete /dev/sdf5 /mnt/data2
ERROR: error removing the device '/dev/sdf5' - Inappropriate ioctl for
device
>
> very strange. 'btrfs fi show -m' shows btrfs fs(s) that are mounted.
Looks like my /dev/sdf isn't responding with
Commit 3a8b36f37806 ("Btrfs: fix data loss in the fast fsync path") added
a performance regression for that causes an unnecessary sync of the log
trees (fs/subvol and root log trees) when 2 consecutive fsyncs are done
against a file, without no writes or any metadata updates to the inode in
between
On Wed, Apr 1, 2015 at 7:41 AM, Anand Jain wrote:
>
>
>> +bool debugfs_abort_transaction(struct btrfs_fs_info *fs_info)
>> +{
>> + if (!btrfs_debugfs_label_trans_abort[0])
>> + return false;
>> + return strcmp(fs_info->super_copy->label,
>> + btrfs_deb
We provided format | in command line.
But btrfs device stats doesn't work if device is not mounted.
Also fix some tailing whitespace.
Signed-off-by: Chen Hanxiao
---
Documentation/btrfs-device.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/btrfs-devi
Cleanup the rb_tree merge/insert/update functions, since now we use list
instead of rb_tree now.
Signed-off-by: Qu Wenruo
---
fs/btrfs/delayed-ref.c | 174 -
1 file changed, 174 deletions(-)
diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-r
The old rbtree implement of ref_head->ref_root sacrificed the insert
order to do better delayed_ref_node merging.
However the out of order behavior makes btrfs_find_all_roots() unable to
find correct root, since it needs the insert order to skip later
delayed_nodes.
Without such ability, qgroup ca
Hi,
On 01.04.2015 10:03, Omar Sandoval wrote:
On Tue, Mar 31, 2015 at 10:54:55PM -0500, Eric W. Biederman wrote:
Omar Sandoval writes:
On Mon, Mar 30, 2015 at 02:30:34PM +0200, David Sterba wrote:
On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
Before commit bafc9b754f75 ("v
Old __merge_refs() in backref.c will even merge refs whose root_id are
different, which makes qgroup gives wrong result.
Fix it by checking ref_for_same_block() before any mode specific works.
Signed-off-by: Qu Wenruo
---
fs/btrfs/backref.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletio
This patch replace the rbtree used in ref_head to list.
This has the following two advantages:
1) Qgroup codes now get an accurate view on the delayed_ref order.
This is the basis for the improved qgroup codes.
2) Easier merge logic.
With the new list implement, we only need to care merging the ta
If no one disagree, I'll try to implement it using list.
In fact, after an easy patch and some tests, it doesn't bring much
performance regression, and delayed_ref_nodes are still mergeable.
Thanks,
Qu
Original Message
Subject: Is rbtree really needed to restore ref_root in
btrfs device delete /dev/sdf5 /mnt/data2
ERROR: error removing the device '/dev/sdf5' - Inappropriate ioctl for
device
very strange. 'btrfs fi show -m' shows btrfs fs(s) that are mounted.
- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
On Tue, Mar 31, 2015 at 10:54:55PM -0500, Eric W. Biederman wrote:
> Omar Sandoval writes:
>
> > On Mon, Mar 30, 2015 at 02:30:34PM +0200, David Sterba wrote:
> >> On Mon, Mar 30, 2015 at 02:02:17AM -0700, Omar Sandoval wrote:
> >> > Before commit bafc9b754f75 ("vfs: More precise tests in d_inval
49 matches
Mail list logo
