BTRFS RAID in this configuration, good.
--
With Best Regards,
Marat Khalili
--
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 reading this list
and own attempts to recover from ENOSPC. I'd rather re-create filesystem
from scratch, or at least make full verified backup before attempting to
fix problems with balance.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscr
ple filling whole cases with WD Greens and observing their (non-BTRFS)
RAID 6 fail.
(Sorry for OT.)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
increased)
Out of curiosity, how does it interacts with nocow files? Does every
write to these files involves backref walk?
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
.
--
With Best Regards,
Marat Khalili
--
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
. So no, a 2 hour job is not a
problem for cron.
Minor additional advice -- prepend you command with:
flock --nonblock /var/run/scrub.lock
to avoid running several scrubs simultaneously in case one takes more
than 24 hours to finish.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from
On 15/11/17 10:11, waxhead wrote:
hint: you need more than two for raid1 if you want to stay safe
Huh? Two is not enough? Having three or more makes a difference? (Or,
you mean hot spare?)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe
pshots/2017-11-13T23:29:49+00:00
./rsync
Or, specify them in --exclude and avoid using --delete-excluded. Or keep
using -x if it works, why not?
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majo
t;any". I much more often use rsync than cp within the same volume.
--
With Best Regards,
Marat Khalili
--
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
data on disk, but
loss of metadata makes it gone in a moment. Moreover, user is usually prepared
to lose some recently changed data in crash, but not the one that it didn't
even touch.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-
separately mounted volume
with necessary options.
--
With Best Regards,
Marat Khalili
--
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
/ ).
--
With Best Regards,
Marat Khalili
--
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
ate petabytes of data
for kernel to process, which it won't be able to do in many years.
--
With Best Regards,
Marat Khalili
--
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://vg
for a day)? Just metadata, not data extents.
--
With Best Regards,
Marat Khalili
--
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
.
--
With Best Regards,
Marat Khalili
--
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
atomic operations which
either succeed or fail. But it's of course hard to be sure without
seeing all actual messages, probably there's some use for 4 levels.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
scripts and force one to remember btrfs commands one has to add it
after. This is already inconvenient enough to want a fix.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
re `| grep -v` with errexit and pipefail on is so difficult
that I usually end up rewriting whole mess in Python. Which would be
nice result in itself if it didn't take a whole day in place of one
minute for bash line.)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: sen
On 25/09/17 10:30, Nikolay Borisov wrote:
On 19.09.2017 10:41, Misono, Tomohiro wrote:
"btrfs subvolume create/delete" outputs the message of "Create/Delete
subvolume ..." even when an operation fails.
Since it is confusing, let's outputs the message only when an operation
succeeds.
Please
Would be cool, but probably not wise IMHO, since on modern hardware you almost
never get one-bit errors (usually it's a whole sector of garbage), and
therefore you'd more often see an incorrect recovery than actually fixed bit.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from
efficiently by analyzing /proc/mounts .
--
With Best Regards,
Marat Khalili
--
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
O_DIRECT work on BTRFS is
difficult if not impossible. Isn't it time to disable O_DIRECT like ZFS
does AFAIU? Data safety is certainly more important than performance
gain it may or may not give some applications.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line
problem as
described by the link, but I'm still worried that particularly qemu can
be less resilient to partial raid1 failures even on newer kernels, due
to missing checksums for instance. (BTW I didn't find any xattrs on my
VM images, nor do I plan to set any.)
--
With Best Regards,
Marat
cannot have all nice things :(
I think I'll simply try to minimize size of VM root partitions and won't
think too much about gig or two extra zeroes in backup, at least until
some autopunchholes mount option arrives.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send
.
--
With Best Regards,
Marat Khalili
--
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 12/09/17 12:21, Timofey Titovets wrote:
Can't reproduce that on latest kernel: 4.13.1
Great! Thank you very much for the test. Do you know if it's fixed in
4.10? (or what particular version does?)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line
n't it try another copy and when does it
correct the error then? Any idea on how to work it around at least for
qemu? (Assemble the array from within the VM?)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
migrating data from HDD and remove the it. I wonder where else
can I look?
--
With Best Regards,
Marat Khalili
--
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
raid to reboot and find /dev/sdb7 mounted again?
* I will not be able to easily mount /dev/sdb7 on a different computer
to do some tests?
Also, although /dev/sdd7 is much larger than /dev/sdb7 was, `btrfs fi
show` still displays it as 2.71TiB, why?
--
With Best Regards,
Marat Khalili
It doesn't need replaced disk to be readable, right? Then what prevents same
procedure to work without a spare bay?
--
With Best Regards,
Marat Khalili
On September 9, 2017 1:29:08 PM GMT+03:00, Patrik Lundquist
<patrik.lundqu...@gmail.com> wrote:
>On 9 September 2017 at 12:05, Mara
Forgot to add, I've got a spare empty bay if it can be useful here.
--
With Best Regards,
Marat Khalili
On September 9, 2017 10:46:10 AM GMT+03:00, Marat Khalili <m...@rqc.ru> wrote:
>Dear list,
>
>I'm going to replace one hard drive (partition actually) of a btrfs
>raid1. Ca
in Current_Pending_Sector line of smartctl output as of
now, so it probably won't heal by itself.
--
With Best Regards,
Marat Khalili
--
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
will it be perhaps 4KB+128KB or something much worse?
--
With Best Regards,
Marat Khalili
--
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
to 4.10 if necessary (it's
Ubuntu that gives us this strange choice, no idea why it's not 4.9).
Only spinning rust here, no SSDs.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.
r, but in everyday operation there's no
significant difference.
--
With Best Regards,
Marat Khalili
--
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
:Ubuntu 16.04.3 LTS
Release:16.04
Codename:xenial
$ df -T | grep /mnt/data/lxc
$ df -T /mnt/data/lxc
Filesystem Type 1K-blocks Used Available Use% Mounted on
- -2907008836 90829848 2815107576 4% /mnt/data/lxc
--
With Best Regards,
Marat Khalili
as a part some
higher-level subvolume, but this higher-level subvolume does not have to
be root. Do you need volume root or just some higher-level subvolume
that's mounted?
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i
Regards,
Marat Khalili
--
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
l you what you already know: some btrfs
operations are painfully slow.
--
With Best Regards,
Marat Khalili
--
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
some recently?
More info about your system would help too.
--
With Best Regards,
Marat Khalili
--
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
space because I can reflink it and then write another 1000 bytes
of data into it without losing 1000 bytes I already have or getting out of
drive space. (Or is it only true while there are open file handles?)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsu
--
With Best Regards,
Marat Khalili
--
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
check historical kernel messages just in case,
and/or unmount and reconnect to be sure.
--
With Best Regards,
Marat Khalili
--
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
ing absolutely
critical, better look to other, more mature filesystems. After all, as adage
says: "legacy is what we run in production".
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ma
using previous state
of two rewritten strips, parity and data? I don't understand all
performance implications, but it might scale better with number of devices.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
ight,
right?
--
With Best Regards,
Marat Khalili
--
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
.
Therefore you need _at least_ WD Red or alternative from Seagate. Paying
more can only bring you quantitative benefits AFAIK. Just don't put
desktop drives in RAID.
(Sorry for being off-topic, but after some long recent discussions I
don't feel as guilty. :) )
--
With Best Regards,
Marat Khalili
,
Marat Khalili
--
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
that qgroups
cause performance problems. I try to avoid deleting many snapshots at
once because of this.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majo
Hit "Send" a little too early:
More complete workaround would be delayed cleanup. What about
(re-)mount time? (Should also handle qgroups remaining
... after subvolumes deleted on previous kernels.)
--
With Best Regards,
Marat Khalili
On 23/05/17 08:38, Marat Khalili wrote:
.
Some people doing cleanup in the reverse order? Other than this, I don't
understand why this feature is needed, so IMO it's unlikely to be needed
in a new API.
Of course, this is all just one datapoint for you.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send
Indeed. This has been tried before, and I don't think it came to
anything.
What can/did go wrong?
I suspect it's still only capturing metadata, rather than data.
Yes. But data should still be there, on disk, right?
--
With Best Regards,
Marat Khalili
--
To unsubscribe from
On 11/05/17 18:19, Chris Murphy wrote:
btrfs-image
Looks great, thank you!
--
With Best Regards,
Marat Khalili
--
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.
may be overwritten between backup and
restore moments, but due to checksumming it can easily be caught (and
either individually restored from backup or discarded).
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i
layer between BTRFS and hardware. Are you sure it's not the bottleneck
in this case?
--
With Best Regards,
Marat Khalili
On 10/05/17 10:02, Stefan Priebe - Profihost AG wrote:
I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me
something about the expected runtime or how
GlobalReserve, single: total=336.00MiB, used=0.00B
marat@host:~$ sudo lxc-attach -n container-name cat /proc/mounts |
grep sda7
/dev/sda7 / btrfs
rw,relatime,space_cache,subvolid=802,subvol=/lxc/container-name/rootfs 0 0
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send
limitations for running qgroups before, only
about CPU load (which importantly only requires patience, does not crash
servers).
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
,
Marat Khalili
--
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
, compatibility and general readiness, and may
contain links (to btrfs wiki?) for more information. I expect whole file
to easily fit in 512 bytes.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
stable/mainstream? Also, won't running these
tools exacerbate often mentioned stability/performance problems with
too-many-snapshots? Any first-hand experience is very welcome.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs&q
th WD Red-s in RAID5
configuration. They are no longer produced and getting harder and harder
to source, but showed themselves as very reliable. According to lsusb
they contain JMicron JMS567 SATA 6Gb/s bridge.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the lin
/dsm/Btrfs
. Somebody forgot to tell Synology, which already supports btrfs in all
hardware-capable devices. I think Rubicon has been crossed in
'mass-market NAS[es]', for good or not.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btr
too buggy.
Thank you very much for this hint. The card is indeed unknown factor
here and I'll keep a close eye on it. The chip is ASM1142, not Intel/AMD
sadly but quite popular nevertheless.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscri
metadata operations there, and
simply moving large amount of data never created any problems for me
regardless of filesystem.
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
uname -a; btrfs --version
Linux host 4.4.0-66-generic #87-Ubuntu SMP Fri Mar 3 15:29:05 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
btrfs-progs v4.4
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
need to implement and
support them :)
Here I'd like to wrap up since I seriously doubt any real btrfs
developers are still reading our discussion :)
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
, but this is not probably what you mean.
--
With Best Regards,
Marat Khalili
--
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
hierarchy is for).
In my system I found it convenient to include subvolume and its
snapshots in qgroup 1/N, where 0/N is qgroup of bare subvolume. I think
adopting this behaviour as default would be more sensible.
--
With Best Regards,
Marat Khalili
On 28/03/17 14:24, Austin S. Hemmelgarn wrote
in chronological order to some folder and re-take snapshots of
that folder, thus recreating your snapshots structure on target.
Obviously, it can/should be automated.
--
With Best Regards,
Marat Khalili
On 26/03/17 06:00, J. Hart wrote:
I have a Btrfs filesystem on a backup server. This filesystem
Suddenly discovered undocumented (in man or anywhere) -i parameter of
'btrfs subvolume snapshot' that adds snapshot to qgroup without
invalidating statistics. Amazing!
--
With Best Regards,
Marat Khalili
On 08/02/17 18:46, Marat Khalili wrote:
I'm using trying to use qgroups to keep track
host 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
btrfs-progs v4.4
--
--
With Best Regards,
Marat Khalili
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More
71 matches
Mail list logo
