I managed to break my root partition today. Playing with GPU
passthrough to a second graphics card, unsuccessfully, I suspect lead to
some lockups and/or unclean mounts.
I've Googled a bit and tried a number of things stopping just before
'btrfs check --repair'. I'm running kernel 4.19.10. I no
On 12/21/2018 10:25 PM, Chris Murphy wrote:
> On Thu, Dec 20, 2018 at 3:23 PM Peter Chant wrote:
>>
>> I managed to break my root partition today. Playing with GPU
>> passthrough to a second graphics card, unsuccessfully, I suspect lead to
>> some lockups and/or uncl
On 12/24/18 12:58 AM, Chris Murphy wrote:
> On Sat, Dec 22, 2018 at 10:22 AM Peter Chant wrote:
>
>> btrfs rescue super -v /dev/sdb2
> ...
>> All supers are valid, no need to recover
>>
>>
>> btrfs insp dump-s -f
> ...
>> generatio
On 12/24/18 2:00 AM, Qu Wenruo wrote:
> I'd recommend to use "btrfs check -r 1113911951360" to verify if it's
> only superblock generation corrupted.
(cancelled "btrfs-image -ss -c9 -t4 -w /dev/sdd2
/mnt/backup/btrfs_issue_dec_2018/btrfs_root_image_error_with_w_20181224.img"
as it said it was g
I attempted update an i5 machine today with kernel 5.2.7. Unfortunately
I could not mount the file system. However, reverting the kernel back
to 5.1.4 allowed it to mount with no issue.
This issue is not critical to me, machine boots with older kernel, I
have a backup and the machine is only lig
Chasing IO errors. BTRFS: error (device dm-2) in
btrfs_run_delayed_refs:2907: errno=-5 IO failure
I've just had an odd one.
Over the last few days I've noticed a file system blocking, if that is
the correct term, and this morning go read only. This resulted in a lot
of checksum errors.
Having
On 8/20/19 10:59 PM, Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>>
>> Chasing IO errors. BTRFS: error (device dm-2) in
>> btrfs_run_delayed_refs:2907: errno=-5 IO failure
>>
>>
>> I've just had an odd one.
>>
&g
hings
On 8/20/19 10:59 PM, Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 3:10 PM Peter Chant wrote:
>>
>> Chasing IO errors. BTRFS: error (device dm-2) in
>> btrfs_run_delayed_refs:2907: errno=-5 IO failure
>>
>>
>> I've just had an odd one.
>
On 8/21/19 8:29 AM, Qu Wenruo wrote:
>> I'll run the checks shortly.
>
> Well, check will also report that transid mismatch, and possibly a lot
> of extent tree corruption.
>
Depends on what is 'a lot', over 400 lines here:
parent transid verify failed on 11000765267968 wanted 2265511 found 2
On 9/23/19 7:55 PM, Pete wrote:
> I'm not sure the balance is resolving anything. The filesystem has not
> gone read only. I'll try an unfiltered balance now to see how that goes.
>
OK, result of unfiltered balance:
root@phoenix:/var/lib/lxc# btrfs bal start /var/lib/lxc
WARNING:
Ful
I got this kernel warning overnight. Possibly during or after a dedup
using duperemove. I'm not sure if that is relevent. Seems to relate to
fs/btrfs/backref.c line 1266.
Don't know if it is important. Thought I'd post it just in case.
I'm afraid this is a screen-shot in the old fashioned sen
On 07/12/2018 07:10 AM, Nikolay Borisov wrote:
>
>
> On 10.07.2018 10:04, Pete wrote:
>> I've just had the error in the subject which caused the file system to
>> go read-only.
>>
>> Further part of error message:
>> WARNING: CPU: 14 PID: 1351 at fs/btrfs/extent-tree.c:3076
>> btrfs_run_delayed_r
he system when I did the backup. That way, should it be necessary, I
> can boot the backup and have a fully functional system exactly as it was
> the day I took that backup. That's very nice to have for a maintenance
> setup, since it means I have access to full manpages, even a full X,
Sirs,
my recently slowing file system is now going read only after trying a
defrag or other operation. I'm wondering whether this is the result of
a hardware failure or a btrfs or some other issue. Output of dmesg:
127.750401] DR0: DR1: DR2:
On 07/02/2013 08:29 AM, Hugo Mills wrote:
This is usually an indication that you have bad hardware -- I'd
suggest testing RAM, PSU, CPU in that order. I'm not sure what, if
anything, can be done to fix the error on the disk right now.
Thanks, appreciated.
Hmm. I've got one stick of ram out
On 07/02/2013 06:48 PM, Hugo Mills wrote:
So the damage probably happened then, if that stick is bad.
Filesystems have this irritating habit of remembering things done to
them across reboots. :) Hugo.
The previous action to the defrag was to delete 48 hours worth of
hourly snapshots. I was
am
prepared to live with this as the subvolumes and snap-shotting are
valuable to me.
Pete
--
Peter Chant
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ng point. The changes are not too radical, all I
need to do is add code to my snapshot scripts to mount and unmount my
toplevel btrfs tree when performing a snapshot. Not sure if this causes
any sigificant time penulty as in slowing of the system with any heavy
IO. Since snapshots are run by cron then the time taken to complete is
not critical, rather whether the act of mounting and unmounting causes
any slowing due to heavy IO.
It does not seem to offer too many absolutes in the way of security or
does it? I suppose it does, for a normal user, remove access to older
binaries that may have shortcomings. Suspect permissions could solve
that as well.
Food for thought in any case. Thank you.
Pete
--
Peter Chant
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
theory disrupt ongoing I/O
> temporarily, but that's limited to writable mounts where some serious
> write-activity occurred, such that if you're just mounting to do a
> snapshot and umounting again, I don't believe that should be a problem,
> since in the normal case there wi
19 matches
Mail list logo
