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
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
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
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
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
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
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
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
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.
"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)
!!!
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
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.
>
>
> > >
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:
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
---
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
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
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
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
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
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.
>
On 2018年06月07日 14:21, Eryu Guan wrote:
> On Fri, Jun 01, 2018 at 09:34:48AM +0800, Qu Wenruo wrote:
>> 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
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: Nikolay Borisov
> Date: Mon May 28 09:36:50
On 05/31/2018 07:40 PM, David Sterba wrote:
On Tue, May 15, 2018 at 09:33:21AM +0800, 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 devel.
symlinks should never have append/immutable attributes.
This
There are two bad symlinks in the test case. One is with immutable
attribute. Another one is with append attribute.
Signed-off-by: Su Yue
Signed-off-by: David Sterba
---
.../034-bad-inode-flags/default_case.img | Bin 0 -> 4096 bytes
tests/fsck-tests/034-bad-inode-flags/test.sh |
Define new macro I_ERR_ODD_INODE_FLAGS to represents odd inode flags.
Symlinks should never have append/immutable flags.
While processing inodes, if found a symlink with append/immutable
flags, mark the inode record with I_ERR_ODD_INODE_FLAGS.
This is for original mode.
Issue: #133
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: Nikolay Borisov
Date: Mon May 28 09:36:50 2018 +0300
btrfs-progs: Remove fs_info
Define new error bit INODE_FLAGS_ERROR to represents invalid inode
flags error.
Symlinks should never have append/immutable flags set.
While checking inodes, if found a symlink with append/immutable
flags, report and record the inode flags error.
This is for lowmem mode.
Issue: #133
On Fri, Jun 01, 2018 at 09:34:48AM +0800, Qu Wenruo wrote:
> 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
46 matches
Mail list logo
