Hi.
When run this script
***
#!/bin/zsh
setopt RC_EXPAND_PARAM
if [[ $1 == start ]]
then
if iscsiadm -m node -L all && mount /mnt/worldvol && mount /MasterVol &&
mount ~foo/local
...
***
failed with
mount: /MasterVol: mount(2) system call failed: File exists.
message after last month Manj
On Tue, Feb 05, 2019 at 02:53:11PM +0800, Qu Wenruo wrote:
> Unlike kernel, btrfs-progs doesn't (yet) support devices grow/shrink,
> the port only needs to handle open_ctree() time initialization (at
> read_one_dev()), and btrfs_add_device() used for mkfs.
>
> This provide the basis for incoming u
On Thu, Jan 31, 2019 at 06:05:40PM +0800, Anand Jain wrote:
> User space understands the ioctl BTRFS_IOC_DEV_REPLACE command status
> using the struct btrfs_ioctl_dev_replace_args::result, and so userspace
> initializes this to BTRFS_IOCTL_DEV_REPLACE_RESULT_NO_RESULT, so exclude
> this value in ch
On Wed, Feb 27, 2019 at 01:49:52PM +0800, Qu Wenruo wrote:
> GCC 8.2.1 will report the following error:
>
> check/main.c: In function 'try_repair_inode':
> check/main.c:2606:5: warning: 'ret' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> if (!ret) {
>^
>
Problem happens with btrfsprogs 4.19.1
https://bugzilla.kernel.org/show_bug.cgi?id=202717
That bug report includes the trace in user space; but I've also
processed the resulting coredump file with gdb and attached that to
the bug report.
Before using --clear-space-cache v1, btrfs scrub and btrfs
On 2019/3/2 上午8:20, Chris Murphy wrote:
> Problem happens with btrfsprogs 4.19.1
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202717
>
> That bug report includes the trace in user space; but I've also
> processed the resulting coredump file with gdb and attached that to
> the bug report.
>
On Fri, Mar 1, 2019 at 6:05 PM Qu Wenruo wrote:
>
>
>
> On 2019/3/2 上午8:20, Chris Murphy wrote:
> > Problem happens with btrfsprogs 4.19.1
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=202717
> >
> > That bug report includes the trace in user space; but I've also
> > processed the resulting
OK this is screwy. The super has a totally different generation for
the root tree than any of the backup roots.
$ sudo btrfs rescue super -v /dev/mapper/sdd
All Devices:
Device: id = 1, name = /dev/mapper/sdc
Device: id = 2, name = /dev/mapper/sdd
Before Recovering:
[All good supers]:
Two more strange things:
# btrfs check -r 930086912 /dev/mapper/sdd
Opening filesystem to check...
parent transid verify failed on 930086912 wanted 4514 found 4076
parent transid verify failed on 930086912 wanted 4514 found 4076
parent transid verify failed on 930086912 wanted 4514 found 4076
pare
On 2019/3/2 上午10:29, Chris Murphy wrote:
> On Fri, Mar 1, 2019 at 6:05 PM Qu Wenruo wrote:
>>
>>
>>
>> On 2019/3/2 上午8:20, Chris Murphy wrote:
>>> Problem happens with btrfsprogs 4.19.1
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=202717
>>>
>>> That bug report includes the trace in user
Is there any user-space tool that can produce report similar to "btrfs
qgroup show" with multi-level qgroups? To clarify what I mean - here is
"btrfs qgroup show" output from openSUSE with enabled snapper.
qgroupid rfer excl parent
--
...
0/25
11 matches
Mail list logo
