February 19, 2021 2:45 PM, "Graham Cobb" wrote:
> On 19/02/2021 17:42, Joshua wrote:
>
>> February 3, 2021 3:16 PM, "Graham Cobb" wrote:
>>
>>> On 03/02/2021 21:54, jos...@mailmag.net wrote:
>>
>> Good Evening.
>>
>> I h
either.
Here's what my fstab looks like, let me know if this is not what you meant!
UUID={snip} / ext4 errors=remount-ro 0 0
UUID={snip} /mnt/data btrfs
defaults,noatime,compress-force=zstd:2,x-systemd.mount-timeout=300s 0 0
However, the system still fails to mount in less than 5 minutes, and drops to
emergency mode.
Upon checking dmesg logs, it is clear the system is only wait 120 seconds,
before giving up on mounting, and dropping to emergency mode.
--Joshua
e
>
> So unfortunately, no good short term solution yet.
>
> THanks,
> Qu
Thanks for the information, that's more or less what I was wondering, but
didn't really know.
Luckily the solution proposed by Graham appears to be working, and 'solved' the
problem
Good Evening.
I have a large BTRFS array, (14 Drives, ~100 TB RAW) which has been having
problems mounting on boot without timing out. This causes the system to drop to
emergency mode. I am then able to mount the array in emergency mode and all
data appears fine, but upon reboot it fails again.
December 26, 2018 11:15 PM, "Duncan" <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Wed, 26 Dec 2018 17:36:19 -0700 as excerpted:
>
>> I'm not really following this. An fs resize is implied by any device
>> add, remove or replace command. In the case of replace, it will
>> efficiently cop
I generally use this command to check my drive usage: `btrfs fi usage -T
/mnt/data` But this time
it didn't give me useful information:
I decided to begin replacing a few of my drives with larger drives, so I could
remove a lot of my
smaller drives. I ran this command:
Overall:
Device size: 67.3
> I have a 25TB mirrored filesystem that I'm able to consistently freeze
> by ungzipping a large file.
> The filesystem scrubs complete without errors and smartd reports no
> errors at the moment.
>
> The command is:
> gzip -dc /btrfsarray/largefile.gz > /btrfs/db/output.sql
> At around 31GB it qu
I'm now running ram tests today. After that, I can get the metadata
dump and the debug command. Tonight, I will get you this info.
Thank you for your help.
Sincerely,
Joshua
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
I have a large-ish filesystem, and it's starting to cause problems
after some SATA errors.
After scrubs stalled, and reading of people with similar errors, I
downloaded the latest btrfs-progs and attempted a btrfsck - is
segfaults. This is ubuntu 14.04, running the mainline kernel 3.19.5.
I down
No luck of catching it in the act unfortunately, but I'll bear that
tip in mind for any future issues.
On Mon, May 19, 2014 at 4:00 AM, Chris Murphy wrote:
>
> On May 18, 2014, at 10:36 AM, Joshua McKinney wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=76421
&
https://bugzilla.kernel.org/show_bug.cgi?id=76421
Perceived issue: SABNZBD hangs, requires restart.
Diagnosis shows the following in my system log at the time of hang.
This happens more than once.
Log:
[ 5883.464766] INFO: task SABnzbd.py:994 blocked for more than 120 seconds.
[ 5883.464906]
never
guaranteed forward compatibility. So it is not yet supported to mount
the fs with an older kernel once it was mounted with a newer one.
Especially when using features that are under heavy development right now.
Also try to keep your kernel up to date (3.13 is out since a few days)
Joshua
or a rescue cd
>
> I did find the -o degraded argument in the wiki now that you mentioned
> it - but it's not prominent enough if you ask me. =)
>
>
[snip]
Joshua
--
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
t=raidn.
> Also persists even if I both scrub AND sync the array before shutting
> the machine down and removing one of the disks.
>
> What's up with this? This is a MASSIVE bug, and I haven't seen anybody
> else talking about it... has nobody tried actually failing out a
Thank you. it worked with 3.12.0 :)
On Fri 22 Nov 2013 10:44:41 GMT, Joshua wrote:
> Hi Stefan,
>
> Thank you for replying. I am running on a 3.10 kernel, will upgrade it
> and check.
>
> Regards
>
> On Fri 22 Nov 2013 10:34:08 GMT, Stefan Behrens wrote:
>> Re:
Hi Stefan,
Thank you for replying. I am running on a 3.10 kernel, will upgrade it
and check.
Regards
On Fri 22 Nov 2013 10:34:08 GMT, Stefan Behrens wrote:
> Re: Receive fails (Could not find parent subvolume)
>
> On Fri, 22 Nov 2013 01:47:43 -0800, Joshua Varghese wrote:
> >
Hi,
I'm trying to implement a mechanism for incremental backup using btrfs.
I have two hardisks and each has a btrfs partition on it. I am able to
take a snapshot of the source partition and send it to the backup disk
using the send-recieve mechanism. When I try to send an incremental
backup of a
;
> Rick
Hi Rick,
use
btrfs fi resize :max
to make btrfs use all space of disk
Joshua
--
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
gt; actually copy out all the xattrs?
rsync has the -X option. rdiff-backup autodetects whether xattrs are
supported.
Those are the programs I use; dunno about others.
-- Josh
--
Joshua J. Berry
"I haven't lost my mind -- it's backed up on tape somewhere."
-- /usr/
would be preferable to some btrfs-specific tunable, as
programs like rsync or backup tools would be able to preserve (and restore)
these bits with no extra work required.
-- Josh
--
Joshua J. Berry
"I haven't lost my mind -- it's backed up on tape somewhere."
-- /usr/ga
f a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm also very interested in this, for incremental backups. I use rdiff-backup
currently, and being able to do this would likely give an impressive speed
boost.
-- Josh
--
Joshua J. Berry
&q
erhaps they should
be made simpler. I honestly can't think of a better interface for something
like this.
-- Josh
--
Joshua J. Berry
"I haven't lost my mind -- it's backed up on tape somewhere."
-- /usr/games/fortune
signature.asc
Description: This is a digitally signed message part.
22 matches
Mail list logo
