Le 28/09/2017 à 19:26, Jean-Denis Girard a écrit :
> Le 28/09/2017 à 15:29, Jean-Denis Girard a écrit :
> FWIW, kernels up to 4.12.14 are ok, and 4.13-rc1 has the same probem.
> Which patches should I try to reverse first?
The problem seems to come from commit c821e7f3 "pass bytes to
btrfs_bio_all
Dirk Diggler posted on Fri, 29 Sep 2017 22:00:28 +0200 as excerpted:
> is there any chance to get my device removed?
> Scrub literally takes months to complete (SATA 2/3 mix, about 1 minute
> per gigabyte) and i'm not sure if that helps.
> I guess same with balance. Mabye there is a quicker way. I
On 30/09/17 19:17, Holger Hoffstätte wrote:
> On 09/30/17 19:56, Holger Hoffstätte wrote:
>> shell hackery as alternative. Anyway, I was sure that at the time the
>> other letters sounded even worse/were taken, but that may just have been
>> in my head. ;-)
>>
>> I just rechecked and -S is still av
On Sat, Sep 30, 2017 at 07:56:25PM +0200, Holger Hoffstätte wrote:
> On 09/30/17 18:37, Graham Cobb wrote:
> > On 30/09/17 14:08, Holger Hoffstätte wrote:
> >> A "root" subvolume is identified by a null parent UUID, so adding a new
> >> subvolume filter and flag -P ("Parent") does the trick.
> >
On 09/30/17 19:56, Holger Hoffstätte wrote:
> shell hackery as alternative. Anyway, I was sure that at the time the
> other letters sounded even worse/were taken, but that may just have been
> in my head. ;-)
>
> I just rechecked and -S is still available, so that's good.
Except that it isn't rea
On 09/30/17 18:37, Graham Cobb wrote:
> On 30/09/17 14:08, Holger Hoffstätte wrote:
>> A "root" subvolume is identified by a null parent UUID, so adding a new
>> subvolume filter and flag -P ("Parent") does the trick.
>
> I don't like the naming. The flag you are proposing is really nothing to
>
Raw oops dump:
[ 173.695170] ==
[ 173.695175] WARNING: possible circular locking dependency detected
[ 173.695181] 4.14.0-0.rc2.git3.1.fc28.x86_64 #1 Tainted: G OE
[ 173.695186] --
30.09.2017 17:53, Peter Grandi пишет:
>> I am trying to figure out which means "top level" in the
>> output of "btrfs sub list"
>
> The terminology (and sometimes the detailed behaviour) of Btrfs
> is not extremely consistent, I guess because of permissive
> editorship of the design, in a "let 100
On 30/09/17 14:08, Holger Hoffstätte wrote:
> A "root" subvolume is identified by a null parent UUID, so adding a new
> subvolume filter and flag -P ("Parent") does the trick.
I don't like the naming. The flag you are proposing is really nothing to
do with whether a subvolume is a parent or not:
The values for block group offset, length etc. in btrfs-debugfs' output
are left-aligned, which creates unaligned output and makes the usage
percentage hard to read/process further. This patch adds right-aligning
format specifiers for the number values.
Ideally the format values wouldn't be hardco
> I am trying to figure out which means "top level" in the
> output of "btrfs sub list"
The terminology (and sometimes the detailed behaviour) of Btrfs
is not extremely consistent, I guess because of permissive
editorship of the design, in a "let 1000 flowers bloom" sort
of fashion so that does no
Hi,
I decided I wanted to try if letting btrfs manipulate those extens would
have fixed my issue. So I launched a full balance followed by a
deduplication followed by another full balance. Then I checked the fs once
again: everything got fixed during the data manipulation.
Anyway btrfs check --
Hi,
When listing subvolumes it can be useful to filter out any snapshots;
surprisingly enough I couldn't find an option to do this easily, only
the opposite (list only snapshots).
A "root" subvolume is identified by a null parent UUID, so adding a new
subvolume filter and flag -P ("Parent") does
(please ignore my previous email, because I wrote somewhere "top id" instead of
"top level")
Hi All,
I am trying to figure out which means "top level" in the output of "btrfs sub
list"
ghigo@venice:~$ sudo btrfs sub list /
[sudo] password for ghigo:
ID 257 gen 548185 top level 5 path debian
I
Hi All,
I am trying to figure out which means "top id" in the output of "btrfs sub list"
ghigo@venice:~$ sudo btrfs sub list /
[sudo] password for ghigo:
ID 257 gen 548185 top level 5 path debian
ID 289 gen 418851 top level 257 path var/lib/machines
ID 299 gen 537230 top level 5 path boot
ID 53
Thank you for all your effort.
In "normal" conditions i know that the remove/delete command is working
(i did that some times before).
But in this case it seems that i have some inconsistent data which
prevents the operation to complete.
Am 30.09.2017 um 13:40 schrieb Goffredo Baroncelli:
O
On 09/30/2017 12:40 PM, DocMAX wrote:
> I removed with "echo" command and also physically.
>
> Both quit with I/O error.
Below the step which I used to simulate (in a virtual machine) your issue:
### created the filesystem, and populated it (with about 500MB)
$ sudo mkfs.btrfs --force -d RAID5 -
I removed with "echo" command and also physically.
Both quit with I/O error.
Am 30.09.2017 um 09:16 schrieb Goffredo Baroncelli:
On 09/30/2017 01:06 AM, DocMAX wrote:
Did you removed the disk before mounting (physically or doing echo 1
>/sys/block/xxx/device/delete)? Which steps you perform
On 09/30/2017 01:06 AM, DocMAX wrote:
>>> Did you removed the disk before mounting (physically or doing echo 1
>>> >/sys/block/xxx/device/delete)? Which steps you performed ?
>
> - removed drive physically
>
> - mounted degraded mode
>
> - btrfs dev del -> same i/o error
>
Did you switch off
19 matches
Mail list logo
