On Fri, Jun 8, 2018 at 12:06 AM, Mark Fasheh wrote:
[...]
>> > 2c) I don't think we can really use a dedicated callback without
>> > passing the vfsmount through since Overlayfs ->getattr might call
>> > the lower fs ->getattr. At that point we might as well use getattr.
>> >
>>
>> Did
This is a long existing bug (from 2012) but exposed by a reporter
recently, that when compressed extent without data csum get written to
device-replace target device, the written data is in fact uncompressed data
other than the original compressed data.
And since btrfs still consider the data is c
On 2018年06月08日 12:37, Steve Leung wrote:
> On 06/06/2018 01:27 AM, Qu Wenruo wrote:
>> The patchset can be fetched from github (*):
>> https://github.com/adam900710/btrfs-progs/tree/inline_ram_bytes
>>
>> It's based on David's devel branch, whose HEAD is:
>> commit 0d1c5812e28e286648781c7b35b5423
On 06/06/2018 01:27 AM, Qu Wenruo wrote:
The patchset can be fetched from github (*):
https://github.com/adam900710/btrfs-progs/tree/inline_ram_bytes
It's based on David's devel branch, whose HEAD is:
commit 0d1c5812e28e286648781c7b35b542311cc01aa4 (david/devel)
Author: Matthias Benkard
Date:
07.06.2018 05:50, Christoph Anton Mitterer пишет:
> Hey.
>
> Just wondered about the following:
>
> When I have a btrfs which acts as a master and from which I make copies
> of snapshots on it via send/receive (with using -p at send) to other
> btrfs which acts as copies like this:
> master +-->
On 2018年06月08日 01:07, Daniel Underwood wrote:
> Hi,
>
> I have a raid10-like setup that is failing to mount in rw mode with the error
>
>
> mount: /mnt/media: wrong fs type, bad option, bad superblock on
> /dev/mapper/em1, missing codepage or helper program, or other error
>
> read-only mount
On Sat, May 26, 2018 at 06:27:57PM -0700, Brad Templeton wrote:
> A few years ago, I encountered an issue (halfway between a bug and a
> problem) with attempting to grow a BTRFS 3 disk Raid 1 which was
> fairly full. The problem was that after replacing (by add/delete) a
> small drive with a larg
On 06/08/2018 02:41 AM, james harvey wrote:
On Thu, Jun 7, 2018 at 4:50 AM, Su Yue wrote:
On 06/07/2018 03:20 PM, james harvey wrote:
btrfs_next_extent_item() looks for BTRFS_EXTENT_ITEM_KEY and
BTRFS_METADATA_KEY,
which are the types we're looking for.
Signed-off-by: James Harvey
Revi
On 2018年06月08日 03:57, james harvey wrote:
> "On Thu, Jun 7, 2018 at 3:26 AM, Qu Wenruo wrote:
>> On 2018年06月07日 15:19, james harvey wrote:
>>> On Thu, Jun 7, 2018 at 12:44 AM, Qu Wenruo wrote:
On 2018年06月07日 11:33, james harvey wrote:
> * btrfs_item_key_to_cpu sets key to (10955960320,
On 2018/06/07 21:22, David Sterba wrote:
> On Thu, Jun 07, 2018 at 11:49:58AM +0900, Misono Tomohiro wrote:
>> Initialize all filed of btrfs_inode_item to zero in order to prevent
>> having some garbage, especially for flags field.
>
> Have you observed in practice or is it a matter of precaution?
On Thu, Jun 07, 2018 at 10:38:51AM +0300, Amir Goldstein wrote:
> On Thu, Jun 7, 2018 at 12:38 AM, Mark Fasheh wrote:
> > Hi,
> >
> > We have an inconsistency in how the kernel is exporting inode number /
> > device pairs for user space. There's of course stat(2) and statx(2),
> > but aside from t
On Thu, Jun 7, 2018 at 2:38 PM, Chris Murphy wrote:
> Your very first task right now is to mount ro, and update your
> backups. Don't do anything else until you've done that. It's a
> testimony to Btrfs that this file system mounts at all, even ro, so
> take advantage of this fact before you can
Hi Darrick,
On Thu, Jun 07, 2018 at 11:17:51AM -0700, Darrick J. Wong wrote:
> Looks ok, but could you please update the manpage for
> ioctl_fideduperange to elaborate on when userspace can expect EPERM?
>
> Acked-by: Darrick J. Wong
Yes, good idea. I can handle that.
Thanks,
--Mark
--
So you zero'd the log? Why? You need to slow down and stop making
changes to your file system unless you hate your data and want to lose
it. The log is there to help protect your data, you don't zero the log
except under very specific situations, none of which appear to apply
to your situation.
'b
"On Thu, Jun 7, 2018 at 3:26 AM, Qu Wenruo wrote:
> On 2018年06月07日 15:19, james harvey wrote:
>> On Thu, Jun 7, 2018 at 12:44 AM, Qu Wenruo wrote:
>>> On 2018年06月07日 11:33, james harvey wrote:
* btrfs_item_key_to_cpu sets key to (10955960320, BTRFS_EXTENT_ITEM_KEY,
4096)
!!! Bonus
On Thu, Jun 7, 2018 at 4:50 AM, Su Yue wrote:
> On 06/07/2018 03:20 PM, james harvey wrote:
>>
>> btrfs_next_extent_item() looks for BTRFS_EXTENT_ITEM_KEY and
>> BTRFS_METADATA_KEY,
>> which are the types we're looking for.
>>
>> Signed-off-by: James Harvey
>
> Reviewed-by: Su Yue
btrfs_next_ex
On Thu, Jun 07, 2018 at 10:38:53AM -0700, Mark Fasheh wrote:
> The permission check in vfs_dedupe_file_range() is too coarse - We
> only allow dedupe of the destination file if the user is root, or
> they have the file open for write.
>
> This effectively limits a non-root user from deduping their
Right now we return EINVAL if a process does not have permission to dedupe a
file. This was an oversight on my part. EPERM gives a true description of
the nature of our error, and EINVAL is already used for the case that the
filesystem does not support dedupe.
Signed-off-by: Mark Fasheh
Reviewed-
Hi Al,
The following patches fix a couple of issues with the permission check
we do in vfs_dedupe_file_range(). I sent them out for review twice, a
changelog is attached. If they look ok to you, I'd appreciate them
being pushed upstream.
You can get them from git if you like:
git pull https://gi
The permission check in vfs_dedupe_file_range() is too coarse - We
only allow dedupe of the destination file if the user is root, or
they have the file open for write.
This effectively limits a non-root user from deduping their own read-only
files. In addition, the write file descriptor that the u
btrfs-map-logical -l 10955980800 -b 4096
No extent found at range [10955980800,10955984896)
But, this extent exists. btrfs-debug-tree shows:
item 202 key (10955976704 EXTENT_ITEM 4096) itemoff 8772 itemsize 37
refs 1 gen 62656 flags DATA
shared data backref parent 14265
Hi,
I have a raid10-like setup that is failing to mount in rw mode with the error
mount: /mnt/media: wrong fs type, bad option, bad superblock on
/dev/mapper/em1, missing codepage or helper program, or other error
read-only mounts seem to work and the files seem to be there.
I started having i
On Mon, Jun 04, 2018 at 11:00:30PM +0800, Anand Jain wrote:
> In an instrumented testing it is possible that the mount and
> a newer mkfs.btrfs thread on the same device can race and if the new
> mkfs.btrfs wins it will free the older fs_devices, then the mount thread
> will lead to oops.
>
> Thre
On Thu, Jun 07, 2018 at 12:01:09AM +0800, Anand Jain wrote:
> %fs_devices can be free-ed by btrfs_free_stale_devices() when the
> close_fs_devices() drops fs_devices::opened to zero, but close_fs_devices
> tries to access the %fs_devices again without the device_list_mutex.
>
> Fix this by bringin
Hi,
a pre-release has been tagged. The full 4.17 release will be done next
Thursday.
Only fixes (with tests) or documentation updates will be added, exceptions on
case-by-case basis.
ETA for 4.17 is in +7 days (2018-06-14).
Changes:
* check
* many lowmem mode improvements
* properly
On Thu, Jun 07, 2018 at 03:20:07AM -0400, james harvey wrote:
> Signed-off-by: James Harvey
Applied, thanks. Please don't forget to add the 'btrfs-progs' prefix to
the subject so the patch does not get overlooked.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the bo
On Thu, Jun 07, 2018 at 02:59:23PM +0800, Su Yue wrote:
> Could you replace this patchset with new V3? It fixes the problem
> reported by Misono.
Done, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mor
On Thu, Jun 07, 2018 at 11:49:58AM +0900, Misono Tomohiro wrote:
> Initialize all filed of btrfs_inode_item to zero in order to prevent
> having some garbage, especially for flags field.
Have you observed in practice or is it a matter of precaution?
--
To unsubscribe from this list: send the line
On Fri, Apr 20, 2018 at 04:21:43PM +0200, David Sterba wrote:
> This patchset adds new ioctl similar to TRIM, that provides several
> other ways how to clear the unused space. The changelogs are
> incomplete, for preview not for inclusion yet.
>
> It compiles and has been tested lightly, the clea
On Thu, 2018-06-07 at 04:06 +0200, Mark Fasheh wrote:
> Hi Ian,
>
> On Thu, Jun 07, 2018 at 08:47:28AM +0800, Ian Kent wrote:
> > On Wed, 2018-06-06 at 23:38 +0200, Mark Fasheh wrote:
> > > Hi,
> >
> > I'm not sure I understand what the problem is.
>
> I'll try to elaborate below.
>
>
> > > We
On 7.06.2018 12:10, Su Yue wrote:
>
>
> On 06/07/2018 02:54 PM, Nikolay Borisov wrote:
>>
>>
>> On 7.06.2018 09:55, Su Yue wrote:
>>> This patchset can be fetch from my github:
>>> https://github.com/Damenly/btrfs-progs/commits/odd_inode_flags
>>> It's based on kdave/devel whose HEAD is:
>>>
On 06/07/2018 02:54 PM, Nikolay Borisov wrote:
On 7.06.2018 09:55, Su Yue wrote:
This patchset can be fetch from my github:
https://github.com/Damenly/btrfs-progs/commits/odd_inode_flags
It's based on kdave/devel whose HEAD is:
commit 1c846faaf87fbb01e080c94098c02b1695ed86dd
Author: Nikola
On 06/07/2018 03:20 PM, james harvey wrote:
Signed-off-by: James Harvey
Reviewed-by: Su Yue
---
btrfs-map-logical.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index 8a41b037..59ba731b 100644
--- a/btrfs-map-log
On 06/07/2018 03:20 PM, james harvey wrote:
btrfs_next_extent_item() looks for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_KEY,
which are the types we're looking for.
Signed-off-by: James Harvey
Reviewed-by: Su Yue
---
btrfs-map-logical.c | 3 ++-
1 file changed, 2 insertions(+), 1 dele
On 06/07/2018 03:19 PM, james harvey wrote:
btrfs-map-logical -l 10955980800 -b 4096
No extent found at range [10955980800,10955984896)
But, this extent exists. btrfs-debug-tree shows:
item 202 key (10955976704 EXTENT_ITEM 4096) itemoff 8772 itemsize 37
refs 1 gen 62656 fla
On Thu, Jun 7, 2018 at 12:38 AM, Mark Fasheh wrote:
> Hi,
>
> We have an inconsistency in how the kernel is exporting inode number /
> device pairs for user space. There's of course stat(2) and statx(2),
> but aside from those we simply dump inode->i_ino and super->s_dev. In
> some cases, the dump
btrfs_next_extent_item() looks for BTRFS_EXTENT_ITEM_KEY and BTRFS_METADATA_KEY,
which are the types we're looking for.
Signed-off-by: James Harvey
---
btrfs-map-logical.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index 245101
Signed-off-by: James Harvey
---
btrfs-map-logical.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index 8a41b037..59ba731b 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -39,7 +39,7 @@
static FILE *info_file;
btrfs-map-logical -l 10955980800 -b 4096
No extent found at range [10955980800,10955984896)
But, this extent exists. btrfs-debug-tree shows:
item 202 key (10955976704 EXTENT_ITEM 4096) itemoff 8772 itemsize 37
refs 1 gen 62656 flags DATA
shared data backref parent 14265
On Thu, Jun 7, 2018 at 12:20 AM, Su Yue wrote:
> On 06/07/2018 11:33 AM, james harvey wrote:
>> Using btrfs-progs v4.16:
>>
>> No extent found at range [10955980800,10955984896)
>>
>> But, this extent exists. btrfs-debug-tree shows:
> Make sense. IMP the commit message is too long to read.
> Code
40 matches
Mail list logo
