tly metadata)
corruption for the degraded state to deal with so it may not matter.
I'm really skeptical of btrfsck on degraded fs's so I don't think
that'll help.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@v
On Fri, Jun 24, 2016 at 6:06 PM, Vasco Almeida <vascomalme...@sapo.pt> wrote:
> Citando Chris Murphy <li...@colorremedies.com>:
>> A lot of changes have happened since 4.1.2 I would still use something
>> newer and try to repair it.
>
>
> By repair do you mean
On Fri, Jun 24, 2016 at 11:21 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 24.06.2016 20:06, Chris Murphy пишет:
>> On Fri, Jun 24, 2016 at 3:52 AM, Andrei Borzenkov <arvidj...@gmail.com>
>> wrote:
>>> On Fri, Jun 24, 2016 at 11:50 AM, Hugo Mills <
out what happens. What should happen
is the reconstruct should work for everything except that one file. If
it's reconstructed silently, it should contain visible corruption and
we all collectively raise our eyebrows.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscrib
On Fri, Jun 24, 2016 at 4:16 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> On Fri, Jun 24, 2016 at 8:20 AM, Chris Murphy <li...@colorremedies.com> wrote:
>
>> [root@f24s ~]# filefrag -v /mnt/5/*
>> Filesystem type is: 9123683e
>> File size of /mnt/5/a.
RAID5 pointless.
I don't understand this. Whether the failed disk means a stripe is
missing a data strip or parity strip, if any other strip is damaged of
course the reconstruction isn't going to match checksum. This does not
make raid5 pointless.
--
Chris Murphy
--
To unsubscribe from this
le to determine it was incorrectly
reconstructed. The notes in btrfs/raid56.c recognize the possibility
of parity corruption and how to handle it. But I think that corruption
is inferred. Maybe the parity csums are in some other metadata item,
but I don't see how it's in the csum tree.
--
Chris Murphy
--
roblems with
multiple quota implementations and snapshots and openSUSE does take
many many snapshots. So that could be it. But without a reproducer
it's hard to say what caused it.
--
Chris Murphy
--
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
On Thu, Jun 23, 2016 at 10:56 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Thu, 23 Jun 2016 18:54:28 -0600 as excerpted:
>
>> From the pasted kernel messages:
>>
>>> Linux version 3.18.34-std473-amd64 (root@rl-sysrcd-p11) (gcc version
>&g
tion substituting the first "a" for "g".
In this case, no rmw, no partial stripe modification, and no data
already on-disk is at risk. Even the metadata leaf/node is cow'd, it
has a new logical and physical address as well, which contains
information for all five files.
--
Chri
s check with a
newer version of btrfs-progs, I can't tell from the pasted output what
version you're using but since the kernel is so old, decent chance the
btrfsck is old also.
Chris Murphy
--
Chris Murphy
--
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
sed if Btrfs
reconstructs from parity and doesn't then check the resulting
reconstructed data to its EXTENT_CSUM.
--
Chris Murphy
--
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://vge
On Wed, Jun 22, 2016 at 11:14 AM, Chris Murphy <li...@colorremedies.com> wrote:
>
> However, from btrfs-debug-tree from a 3 device raid5 volume:
>
> item 5 key (FIRST_CHUNK_TREE CHUNK_ITEM 1103101952) itemoff 15621 itemsize 144
> chunk length 2147483648 owner 2 stripe_len 65
t be used for other block group types, such as system or data. So
in some sense it is "used" but strictly speaking it's just a
reservation.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.k
On Mon, Jun 20, 2016 at 7:55 PM, Zygo Blaxell
<ce3g8...@umail.furryterror.org> wrote:
> On Mon, Jun 20, 2016 at 03:27:03PM -0600, Chris Murphy wrote:
>> On Mon, Jun 20, 2016 at 2:40 PM, Zygo Blaxell
>> <ce3g8...@umail.furryterror.org> wrote:
>> > On Mon, Jun
On Mon, Jun 20, 2016 at 2:40 PM, Zygo Blaxell
<ce3g8...@umail.furryterror.org> wrote:
> On Mon, Jun 20, 2016 at 01:30:11PM -0600, Chris Murphy wrote:
>> For me the critical question is what does "some corrupted sectors" mean?
>
> On other raid5 arrays, I would obser
is myself. That's the real problem here as
I see it. Losing a drive is ordinary. Additional corruptions happening
afterward is not. And are those corrupt sectors hardware corruptions,
or Btrfs corruptions at the time the data was written to disk, or
Btrfs being confused as it's reading the data
On Mon, Jun 20, 2016 at 3:22 AM, Tyson Whitehead <twhiteh...@gmail.com> wrote:
> On 17/06/16 06:18 PM, Chris Murphy wrote:
>>
>> On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead <twhiteh...@gmail.com>
>> wrote:
>>>
>>> On May 27, 2016 12:12:54 PM
On Mon, Jun 20, 2016 at 3:22 AM, Tyson Whitehead <twhiteh...@gmail.com> wrote:
> On 17/06/16 06:18 PM, Chris Murphy wrote:
>>
>> On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead <twhiteh...@gmail.com>
>> wrote:
>>>
>>> On May 27, 2016 12:12:54 PM
to get it up. scp it somewhere or if
the file is small enough you can 'fpaste btrfscheck.txt' and it'll
spit back a URL where it uploaded that file.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.ke
p enough such that you'll just get piles
of read errors for the data that's missing rather than hitting some
brick wall and stopping.
--
Chris Murphy
--
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
On Sat, Jun 11, 2016 at 6:40 AM, Jukka Larja <roskak...@aarghimedes.fi> wrote:
> 11.6.2016, 15.30, Chris Murphy kirjoitti:
>
>> On Fri, Jun 10, 2016 at 9:11 PM, Jukka Larja <roskak...@aarghimedes.fi>
>> wrote:
>>
>>> I understand that usebackup
Stretch, I'll give it a try.
It's the "recovery" mount option in older kernels.
--
Chris Murphy
--
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
re those issues something which was fixed since 4.6.0-rc4+ or I should
> be on look out for them to come back? What other information should I
> provide if I run into them again to help you troubleshoot/fix it?
>
> P.S. Please CC me the replies
4.6.2 is current and it's a lot easier to just use that and see if it
still happens than for someone to track down whether it's been fixed
since a six week old RC.
--
Chris Murphy
--
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
e ssd mount option even if (?) this is on an HDD. The
description of the problem sounds like what ssd_spread might do, but
it could be worth trying that one.
And still another, which I put last only because it wouldn't be nearly
so automatic, would actually be to pin the extents from being fr
dvance to
what degree you have loss. It's not a binary condition, it has a gray
area where a lot of data can still be retrieved, but the instant you
hit missing data it's a loss, and if you hit missing metadata then the
fs will either go read only or crash, it just can't continue. So that
&q
On Mon, Jun 6, 2016 at 10:02 PM, Kai Hendry <hen...@iki.fi> wrote:
> Sorry I unsubscribed from linux-btrfs@vger.kernel.org since the traffic
> was a bit too high for me.
>
> On Tue, 7 Jun 2016, at 11:42 AM, Chris Murphy wrote:
>> Your command turned this from a 3 drive volu
oft' should work I
think. If there are single chunks created and not converted, later if
you need to do a degraded mount it will fail. Usually it can be made
to work with -o ro,degraded in such a case, but it means no more
read-write for the file system, you'd have to recreate it (at this
point until it's fixed
int you're confused. It
seems like maybe you're not aware that three drive raid1 still means
two copies of data, not three. Taking one drive would never have
worked anyway.
--
Chris Murphy
--
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
On Sun, Jun 5, 2016 at 4:45 AM, Mladen Milinkovic <max...@smoothware.net> wrote:
> On 06/03/2016 04:05 PM, Chris Murphy wrote:
>> Make certain the kernel command timer value is greater than the driver
>> error recovery timeout. The former is found in sysfs, per block
>
400-50; late Middle English < Latin
duplicātus (past participle of duplicāre to make double), equivalent
to duplic- (stem of duplex) duplex + -ātus -ate1
http://www.dictionary.com/browse/duplicate
There is no possible reading of this that suggests n-way RAID is intended.
--
Chris Murphy
--
T
Btrfs. But when a
developer responds, more than once, about how this is somewhere
between difficult and not possible, and you say it should simply be
possible, I think that's annoying, bordering on irritating.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe li
On Sun, Jun 5, 2016 at 2:31 PM, Christoph Anton Mitterer
<cales...@scientia.net> wrote:
> On Sun, 2016-06-05 at 09:36 -0600, Chris Murphy wrote:
>> That's ridiculous. It isn't incorrect to refer to only 2 copies as
>> raid1.
> No, if there are only two devices then no
On Sat, Jun 4, 2016 at 4:43 PM, Christoph Anton Mitterer
<cales...@scientia.net> wrote:
> On Sat, 2016-06-04 at 13:13 -0600, Chris Murphy wrote:
>> mdadm supports DDF.
>
> Sure... it also supports IMSM,... so what? Neither of them are the
> default for mdadm, nor
cal
device managed by a device mapper variant.
Anyway, I think there's a whole separate github discussion on Btrfs
UI/Ux that presumably also includes terminology concerns like this.
--
Chris Murphy
--
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
On Sat, Jun 4, 2016 at 11:37 AM, Christoph Anton Mitterer
<cales...@scientia.net> wrote:
> On Sat, 2016-06-04 at 11:00 -0600, Chris Murphy wrote:
>> SNIA's DDF 2.0 spec Rev 19
>> page 18/19 shows 'RAID-1 Simple Mirroring" vs "RAID-1 Multi-
>> Mirroring&q
Linux at all anywhere. And for some inexplicable
reason, the TCG hasn't commissioned a free UEFI application for
managing the keys and unlocking the drive in the preboot environment.
For now, it seems, such support has to already be in the firmware.
--
Chris Murphy
--
To unsubscribe from this list: s
;all
>> disks mirrored".
>>
>
> Out of curiosity - which model of hardware controllers? Those I am aware
> of simply won't let you create RAID1 if more than 2 disks are selected.
SNIA's DDF 2.0 spec Rev 19
page 18/19 shows 'RAID-1 Simple Mirroring" vs "RAID-1
6=v4.5
There's no longer such a strongly worded caution in that document, nor
in the wiki.
The wiki has stale information still, but it's a volunteer effort like
everything else Btrfs related.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
bug report. Also, in terms of tuning, I've been unable to find
> whether the ideal kernel timeout value changes depending on RAID
> type...is that a factor in selecting a sane kernel timeout value?
No. It's strictly a value to make certain you get read errors from the
drive rather than l
So if
your use case cannot tolerate such delays, then the drives must be
disqualified.
--
Chris Murphy
--
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
consumer drives, and inevitably leads to problems, even the loss of
the entire array. It really is a terrible default.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
e '/dev/loop0': No space left on device
Well the big problem here is that it's a loop device so even if it
were a known/fixed bug you're stuck being unable to boot; well, except
you could add a big enough device, convert to raid1, and reboot with
rootflags=degraded.
I'd use the external to ma
el and btrfs-profs versions?
--
Chris Murphy
--
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
On Sun, May 29, 2016 at 8:03 PM, Chris Murphy <li...@colorremedies.com> wrote:
>
> # lsblk -o +UUID
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID
> loop07:0010G 0 loop /mnt/0
> 63288b0c-9216-4f11-aed4-cc054ae90e07
> loop17:1010G 0 loo
ence why LVM in the first case, and
fallocated files on loop for the second. I'm not sure what's causing
this.
Chris Murphy
--
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
m that of the seed to that of the sprout.
So both of those seem to depart from the remount definition rather
significantly.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Sun, May 29, 2016 at 12:03 PM, Holger Hoffstätte
<hol...@applied-asynchrony.com> wrote:
> On 05/29/16 19:53, Chris Murphy wrote:
>> But I'm skeptical of bcache using a hidden area historically for the
>> bootloader, to put its device metadata. I didn't realize that was
On Sun, May 29, 2016 at 12:16 PM, Peter Becker <floyd@gmail.com> wrote:
> 2016-05-29 19:11 GMT+02:00 Chris Murphy <li...@colorremedies.com>:
>> On Sat, May 28, 2016 at 3:42 PM, Peter Becker <floyd@gmail.com> wrote:
>>> Thanks for the cla
data that hasn't been committed to
the HDD?
But I'm skeptical of bcache using a hidden area historically for the
bootloader, to put its device metadata. I didn't realize that was the
case. Imagine if LVM were to stuff metadata into the MBR gap, or
mdadm. Egads.
--
Chris Murphy
--
To unsubscribe from
the user wants to use the
same amount of space as the former block device. I think if the user
wanted to use the former block device size on the new block device,
they'd partition it and use the partition as the target.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubs
is the lack of information why a scrub is aborted.
--
Chris Murphy
--
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
This is a three drive or four
drive raid10? This is Btrfs raid10 specifically? I'm confused now
about the setup and why btrfs fi show isn't saying there are missing
devices, there is no such thing as two drive btrfs raid10.
Chris Murphy
--
To unsubscribe from this list: send the line "uns
would be 4.4.1 or better.
Also a good idea is to post btrfs-show-super -f, there's a scant
possibility there's more than one backup chunk root and possible to
explicitly use an older one (but btrfs check--chunk-root is only in
v4.5 of btrfs-progs).
Chris Murphy
--
To unsubscribe from this list
switches to
creating a mixed-bg?
--
Chris Murphy
--
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
On Tue, May 17, 2016 at 3:58 PM, Goni Zahavy <goni1...@gmail.com> wrote:
> On 5/18/16, Chris Murphy <li...@colorremedies.com> wrote:
>> On Tue, May 17, 2016 at 2:27 PM, Goni Zahavy <goni1...@gmail.com> wrote:
>>> Guys, just remember that this crappy-insta
is benchmarking and review it's difficult to say the user
has no role whatsoever in helping prevent it, as tedious as that is.
--
Chris Murphy
--
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
s of
btrfs-defrag.sh being run on a regular basis when opensuse uses
snapper by default, resulting in many dozens or hundreds of read only
snapshots in short order
- btrfs-trim.sh is obsoleted by systemd provided fstrim.timer, which
is enabled by
default, there's no good reason to run both of these;
data vs metadata balancing act for a stable and
production recommended fs.
But at least as much we need better behavior in updaters. Quite a lot
of them it seems make excessive use of fsync for probably no longer
very good reasons.
--
Chris Murphy
--
To unsubscribe from this list: send the line &qu
problems. Only data csums are being corrupt
after they're read in, but before the node csum is computed? Three
times? Pretty wonky.
--
Chris Murphy
--
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
I realized this could be a much bigger problem for single copy
metadata on SSD case, rather than the example using raid1 where it's
unlikely for both copies of the node to be corrupt. So I filed a bug.
https://bugzilla.kernel.org/show_bug.cgi?id=118321
--
To unsubscribe from this list: send the
d. So the only way to test this would be passing all file
from this volume and a reference volume through a hash function and
comparing hashes, e.g. rsync -c option.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
to me how your file data has not changed, but somehow
the extent csum was changed but also the node csum was recomputed
correctly. That's a bit odd.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
returning at all? Why does it return incorrectly?
--
Chris Murphy
--
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
e Btrfs debug options for compile time, and are
enabled with mount options. But I think the problem you're having
isn't specific to Btrfs or someone else would have run into it.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
ould be fraught with peril if the
user makes a mistake. So, really what's the right way to do this is
part of the problem but I agree it's better to be hostile and refuse
to mount a given volume UUID at all when too many devices are found,
than corrupt the file system.
--
Chris Murphy
--
To unsubscri
sdc/device/timeout
> 30
>>
That's appropriate. So at least any failures have a chance of being
fixed before the command timer does a reset on the bus.
--
Chris Murphy
--
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
for each device:
smartctl scterc -l /dev/sdX
cat /sys/block/sdX/device/timeout
--
Chris Murphy
--
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
* errors. So your expectation is proper.
Chris Murphy
--
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
On Mon, May 9, 2016 at 4:56 AM, Alejandro Vargas <a...@zener.es> wrote:
> El Martes, 26 de abril de 2016 00:08:49 Chris Murphy escribió:
>> On Mon, Apr 25, 2016 at 8:03 AM, Alejandro Vargas <a...@zener.es> wrote:
>
>> I suggest unmounting and running 'btrfs chec
ll make a V5 file system that uses
metadata checksumming by default.
--
Chris Murphy
--
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
And then copy the data to a new array before
making any changes to the original volume. And hopefully mounting
degraded,ro works, if not then it's btrfs restore (offline scrape)
time.
--
Chris Murphy
--
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
a software bug or hardware problem, you need to test it with the most
basic setup possible --> btrfs on plain partitions and default mount
options.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vg
ers.stackexchange.com/questions/76765/sent-emails-pass-spf-and-dkim-but-fail-dmarc-when-received-by-gmail
http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-breaks-mailing-lists.html
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs
On Wed, May 4, 2016 at 12:34 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Wed, 04 May 2016 12:07:39 -0600 as excerpted:
>
>> If you think it's worth the hassle, then you have to directly modify the
>> grub.cfg to include an expanded rootflags para
k then you should add boot parameter
systemd.log_level=debug and then after startup put the output from
'journalctl -b -o short-monotonic > journal.log' up somewhere for
others to look at. It will be much larger than usual and will make it
easier to find out where things are getting confused.
it's worth the hassle, then you have to directly modify
the grub.cfg to include an expanded rootflags parameter. Right now
grub-mkconfig logic doesn't not include all options in fstab for
rootflags.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
is
only advised if your SSD supports queued trim, otherwise you should
rely on the systemd fstrim.timer service being enabled instead.
Everything else in your fstab is already the default.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the bod
On Mon, May 2, 2016 at 1:19 PM, Yauhen Kharuzhy
<yauhen.kharu...@zavadatar.com> wrote:
> On Mon, May 02, 2016 at 01:04:30PM -0600, Chris Murphy wrote:
>> On Mon, May 2, 2016 at 12:43 PM, Yauhen Kharuzhy
>> <yauhen.kharu...@zavadatar.com> wrote:
>> > On Sat, Apr
RDDISK1.0
> PQ: 0 ANSI: 5
> [ 424.389067] sd 4:0:0:0: [sdf] 41943040 512-byte logical blocks: (21.5
> GB/20.0 GiB)
> [ 424.389110] sd 4:0:0:0: Attached scsi generic sg4 type 0
> [ 424.453500] sd 4:0:0:0: [sdf] Write Protect is off
sd 4:0:0:0: was sde now it's sdf
I think there's another bug here instigating all of this. I'm not sure
it's a Btrfs bug at all.
--
Chris Murphy
--
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
On Fri, Apr 29, 2016 at 2:20 PM, Alexander Fougner <fougne...@gmail.com> wrote:
> 2016-04-29 22:17 GMT+02:00 Chris Murphy <li...@colorremedies.com>:
>> On Fri, Apr 29, 2016 at 2:01 PM, Alexander Fougner <fougne...@gmail.com>
>> wrote:
>>> Hello,
>>&
pia)/.gradle/2.8/taskArtifacts
> ERROR: cannot open
> srv/backup/optimus/@home.20160403/alex/Android/LNU/Ass1/.gradle/2.8/taskArtifacts/taskArtifacts.bin:
> No such file or directory
>
>
Do scrub and btrfs check (no repair) complete without errors?
--
Chris Murphy
--
To unsubscrib
On Wed, Apr 27, 2016 at 8:51 PM, Chris Murphy <li...@colorremedies.com> wrote:
> On Wed, Apr 27, 2016 at 2:18 PM, Juan Alberto Cirez
> <jaci...@rdcsafety.com> wrote:
>> Quick question: Supposed I have n-number of storage pods (physical
>> servers with n-number of phys
an the
drive's SCT ERC setting.
cat /sys/block//device/timeout
smartctl -l scterc
If the command timer is shorter, bad sectors will not get reported as
read errors for proper fixup, instead there will be a link reset and
it's just inevitable there will be worse problems.
--
Chris Murphy
--
To unsubscrib
On Wed, Apr 27, 2016 at 5:22 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2016-04-26 20:58, Chris Murphy wrote:
>>
>> On Tue, Apr 26, 2016 at 5:44 AM, Juan Alberto Cirez
>> <jaci...@rdcsafety.com> wrote:
>>>
>>>
>>> W
f hot (or cold) spares. They contribute nothing,
but take up physical space and power.
--
Chris Murphy
--
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
s ~]# cat /etc/fstab |grep backup
> LABEL=disco_backup /mnt/backup btrfs noauto,compress=zlib,compress-
> force=zlib,commit=60,noatime 0 0
When I delete subvolumes, I see it takes up to the commit time for the
delete transaction to be committed, and it can be longer than this by
up to a minute
me the workload. I don't
think it has to come to a complete stop but it's a lot more
reproducible with heavy writes.
--
Chris Murphy
--
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
store parameters, maybe use
-f or -d or even -path-regex to find specific files you want to
scrape, and hope for the best. The less you're trying to grab, the
fewer errors, so it's a kind of triage at this point I think, short of
someone else with better ideas.
--
Chris Murphy
--
To unsubscribe from t
On Mon, Apr 18, 2016 at 9:52 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2016-04-18 11:39, Chris Murphy wrote:
>>
>> On Mon, Apr 18, 2016 at 9:15 AM, Austin S. Hemmelgarn
>> <ahferro...@gmail.com> wrote:
>>>
>>>
>>>>
&
require root fs to be in a
new subvolume. It won't install to either subvolid 5, or any other
existing subvolume.
--
Chris Murphy
--
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
working
in Fedora 23, exposed by a Btrfs change disallowing simultaneous use
of subvolid and subvol, resulting in mount failure, which in turn
causes the installer to crash. But it works in Fedora 22, and it will
work in Fedora 24. On the other hand, no Fedora supports Btrfs for
/boot, it has to be s
thereafter.
kernel 4.5.0
--
Chris Murphy
--
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
hat I'm seeing:
[root@f23m 0]# cat /sys/block/zram0/stat
642580 514064 19199490 159592
2140 233 233
Anyway there might be a plausible exception, if there's a good reason,
for the one property per file rule.
--
Chris Murphy
--
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
lem happens when
> the 'parent_uuid' does not exist.
>
> I'm pretty sure this isn't the intended behavior, and it's certainly
> preventing me from copying my backups right now.
Duncan replied to the original post.
http://www.spinics.net/lists/linux-btrfs/msg54275.html
--
Chris Murphy
On Fri, Apr 15, 2016 at 6:07 PM, Liu Bo <bo.li@oracle.com> wrote:
> On Fri, Apr 15, 2016 at 09:28:49AM -0600, Chris Murphy wrote:
>> Note this is a testing VM, no user data is at risk
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=116331
>
>
the problem,
--init-extent-tree crashes
So it's pretty messy fixing wise. But so far -o recovery,ro is letting
me extract important things like the journal.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
t/snaps/root-2016-04-08 true
>
Yeah it's a good start. I'm not sure what the UI should be exactly.
Maybe it could be an ro column that's blank for rw and ro if it's ro.
Something that's easy to parse visually? Also have it line up in a
straight column, probably befor
able to see if it's ro or not is a nice to have.
In particular on openSUSE with snapper where there's a prolific amount
of snapshots, and the naming convention doesn't indicate whether
something is ro or not.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-
same on each drive, so
it's worth checking:
btrfs-show-super -f
And then also btrfs-find-root
--
Chris Murphy
--
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
801 - 900 of 2056 matches
Mail list logo
