On 2018年04月23日 13:08, Dmitrii Tcvetkov wrote:
> On Mon, 23 Apr 2018 09:23:53 +0800
> Qu Wenruo wrote:
>
>> On 2018年04月21日 22:55, Dmitrii Tcvetkov wrote:
>>> TL;DR It seems as regression in 4.17, but I managed to find a
>>> workaround to make filesystem rw mountable again.
>>>
>>> Kernel built f
Hi
Thanks for reporting.
May be the same bug reproduced by using
$sudo TEST=003\* make test-fuzz
in btrfs-progs.
More details in:
https://patchwork.kernel.org/patch/10073937/
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] O
Signed-off-by: Tomohiro Misono
---
tests/cli-tests/009-subvolume-list/test.sh | 136 +
1 file changed, 136 insertions(+)
create mode 100755 tests/cli-tests/009-subvolume-list/test.sh
diff --git a/tests/cli-tests/009-subvolume-list/test.sh
b/tests/cli-tests/009-subvo
Test user 'progs-test' will be used to test the behavior of normal user.
In order to pass this check, add the user by "useradd -M progs-test".
Note that progs-test should not have root privileges.
Signed-off-by: Tomohiro Misono
---
tests/common | 10 ++
1 file changed, 10 insertions(+)
Allow normal user to call "subvolume list" by using 3 new
unprivileged ioctls (BTRFS_IOC_GET_SUBVOL_INFO,
BTRFS_IOC_GET_SUBVOL_ROOTREF and BTRFS_IOC_INO_LOOKUP_USER).
Note that for root, "subvolume list" returns all the subvolume in the
filesystem by default, but for normal user, it returns subvol
This is a preparetion work to allow normal user to call
"subvolume list".
Signed-off-by: Tomohiro Misono
---
btrfs-list.c | 16 +---
btrfs-list.h | 7 ---
cmds-subvolume.c | 2 +-
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list
Add 3 definitions of new unprivileged ioctl (BTRFS_IOC_GET_SUBVOL_INFO,
BTRFS_IOC_GET_SUBVOL_ROOTREF and BTRFS_IOC_INO_LOOKUP_USER). They will
be used to implement user version of "btrfs subvolume list" etc.
Signed-off-by: Tomohiro Misono
---
ioctl.h | 86
After btrfs_list_subvols() is called, root_lookup may hold some allocated
memory area even if the function fails.
Therefore rb_free_nodes() should be called.
Signed-off-by: Tomohiro Misono
---
btrfs-list.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/btrf
This version is only for testing new ioctls[1] with btrfs-progs 4.16 for the
meantime.
Since progs code has changed, "sub show" cannot be run by non-root user with
this version. Also, the behavior difference between root and non-root has not
been settled. I'll continue working on these and send up
P. S. After making partition-level backup to an image file, which
I'll now restore from, tried "btrfs check --repair". It didn't fix
any of the parent transid errors, only "fix" was "cache and super
generation don't match, space cache will be invalidated".
--
To unsubscribe from this list: send t
Arch, kernel 4.15.14, btrfs progs 4.15.1.
Had some SATA drives dropout. Have a few btrfs volumes with parent
transid verify failed errors, that all mount.
This volume has nothing I care about, so I'm just reporting it since
it looks like a bug. None of my other volumes having issues cause
core
Arch, kernel 4.15.14, btrfs progs 4.15.1.
Had some SATA drives dropout during a long copy. Now running off live
ISO. Actually have this issue on a few btrfs volumes, ironically this
happened while implementing a backup system, so looking for best way
forward since it doesn't look like all is los
On 2018/04/21 2:02, David Sterba wrote:
> The new ioctl is an extension to the FS_IOC_SETFLAGS and adds new
> flags and is extensible. Don't get fooled by the XATTR in the name, it
> does not have anything in common with the extended attributes,
> incidentally also abbreviated as XATTRs.
>
> This
On 2018/04/21 2:02, David Sterba wrote:
> Converts btrfs_inode::flags to the FS_*_FL flags.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/ioctl.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 953473f2a136..f0e607
On 2018年04月21日 22:55, Dmitrii Tcvetkov wrote:
> TL;DR It seems as regression in 4.17, but I managed to find a
> workaround to make filesystem rw mountable again.
>
> Kernel built from tag v4.17-rc1
> btrfs-progs 4.16
>
> Tonight two my machines (PC (ECC RAM) and laptop(non-ECC RAM)) were
> doin
On Sat, Apr 21, 2018 at 12:23:58PM -0500, Jayashree Mohan wrote:
> A gentle reminder on the above behavior on btrfs : Even on fsync-ing
> the directory, its entries are not persisted. Could you let us know
> your thoughts on this?
Sending a gentle reminder one day after the report and even on a we
Hi,
the branch contains a few fixups to qgroup patches that were merged this
dev cycle, unaligned access fix, blockgroup removal corner case fix and
a small debugging output tweak.
Please pull, thanks.
The following changes since c
> I saved /home filesystem from laptop in unmountable
> by 4.17-rc1 state and can test patches and/or create
> btrfs-image if it's needed.
Here is link to the image (103 MB):
https://demfloro.ru/static/home-btrfs.image
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
18 matches
Mail list logo
