e 15th of February. It was the kernel patches
>> and was slated for the kernel 4.6 dev cycle. However, the patch set
>> was pulled at that time due to test failures, tho they were suspected
>> to actually be from something else.
>
> Thanks Duncan. Yep the report
es given.
Which explains the error complaining about being unable to find a parent,
when given only clone sources that (based on your reproducer) had nothing
in common with the snapshots listed as clones.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a mas
for me, turned out
to be hardware. I've had no issues since I replaced that failing ssd,
and with a bit of luck, won't be running restore again for a few years,
now.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you
nd that what's not backed up you're
not too worried about losing. Despite btrfs not being entirely stable as
yet, it's surprising the number of cases we see where that's not the case.
So kudos for being a wise sysadmin, and appreciating that data that's not
backed u
remental sends can only be used as long as you have the same previous -
p and -c snapshots to reference on both sides. Don't delete (or change)
your reference unless you either (a) never plan to use it as a send
reference again, or (b) are willing to do a full non-incremental send
course to
Anand Jain for posting the patches so you can. =:^) Your work is
directly contributing to it being more mature at mainline feature
release, so that (unlike raid56) hopefully it can fast-stabilize once
released, because of all the testing and work that is going in now,
before mainlin
cognize the bug and tell you to try a later/earlier version, or if not,
you very well may prompt a new patch, possibly after some further
debugging.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your ma
nd
description for true (1)).
That even a balance with -dusage=0 is actually failing, not just
completing without doing anything as might be expected, is strange
indeed. With a bit of luck that's a strong hint to the devs as to what
has actually gone wrong and how to fix it.
--
Duncan
u're following kernel recommendations, will ensure that you don't get
/too/ far behind with userspace as well, since the version numbers are
synced and a userspace release of a particular series tends to come a
week or so after the corresponding kernel series .0 release. So 4.4 is
gr
in
the specific details, but as I explained above, btrfs now requires a
particular number of devices with writable unallocated space in ordered
to allocate new chunks of the corresponding raid level, two devices for
raid1, for instance. If there's not enough devices with unallocated free
s
s either the btrfs
device ID or as missing-N), and the status of the device being detectable
by whether it's a symlink to a devices tree device (device online) or a
subdir (device offline).
The per-filesystem devices-losable, fs-status, and leave-be files could
be added to the existing syf
h one, but I follow release or development, not
stable, and don't know what stable's current status is.
If it gets to stable, and it wasn't for a bug introduced /after/ 4.4, it
should eventually get into 4.4, as that's an LTS kernel. But it might
take awhile, as the above dis
data on now out of regular service devices... I
expect I could recover most of it, and what I couldn't I'd simply do
without.
> Thank you for explaining the process.
=:^)
FWIW... My dad was a teacher before he retired. As he always said, the
best way to learn something, even better
on the page.
If that's beyond your technical abilities or otherwise doesn't work, you
may be able to use some of the advanced options of btrfs check and btrfs
rescue to help, but I've never tried that myself and you'll be better off
with help from someone else, because unlike rest
prevent this ideal from being
reality in more cases than we'd like, tho the filesystem is in general
stable enough for many to use daily, as many including myself do, as long
as they have backups just in case, and their world won't end if they
actually have to use them.
--
Duncan - List repli
Gareth Pye posted on Tue, 05 Apr 2016 13:45:11 +1000 as excerpted:
> On Tue, Apr 5, 2016 at 12:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> CPU bound, 0% IOWait even at idle IO priority, in addition to the
>> hundreds of M/s values per thread/device, here. You OTOH are sh
Gareth Pye posted on Tue, 05 Apr 2016 13:44:05 +1000 as excerpted:
> On Tue, Apr 5, 2016 at 12:37 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> 1) It appears btrfs scrub start's -c option only takes numeric class,
>> so try -c3 instead of -c idle.
>
>
> Do
m much the wiser on
what copy-back actually entails. =:^)
Tho it seems I was correct in the one aspect, currently ENotImplemented,
even if my idea of what you were asking to be implemented was totally and
completely off-the-wall wrong.
--
Duncan - List replies preferred. No HTML msgs.
&q
.00 % btrfs scrub
start -c3 /p
CPU bound, 0% IOWait even at idle IO priority, in addition to the
hundreds of M/s values per thread/device, here. You OTOH are showing
under 20 M/s per thread/device on spinning rust, with an IOWait near 90%,
thus making it IO bound.
--
Duncan - List repli
sad, but in a majority proprietary or at best don't-care
market...
> I'm also seeing multi_zone_error_rate on my spinning rust.
> According to smartctl health check and smartctl extended selftest,
> there's no problems at all - and the smart error log is empty. There has
Duncan posted on Mon, 04 Apr 2016 04:45:16 + as excerpted:
> Kai Krakow posted on Mon, 04 Apr 2016 02:00:43 +0200 as excerpted:
>
>> Does this also implement "copy-back" - thus, it returns the hot-spare
>> device to global hot-spares when the failed device has
s better than what is currently
available (no automated spare handling at all), and an implementation
must start somewhere, so as long as it's designed to be improved and
extended with the missing features over time, as has been indicated, it's
a reasonable first-implementation.
--
from the other
copy, crashing btrfs and the system, thus requiring more frequent scrubs
than would otherwise be required -- I ran into this too, but didn't
realize it only triggered on compressed content and was thus a specific
bug, and simply attributed it to btrfs not yet being fully stable
the same
spot) or different, and whether putting the file in a different subdir or
using a different name for it matters at all. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Ri
Chris Murphy posted on Fri, 01 Apr 2016 23:43:46 -0600 as excerpted:
> On Fri, Apr 1, 2016 at 10:55 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Marc Haber posted on Fri, 01 Apr 2016 15:40:29 +0200 as excerpted:
>
>>> [4/502]mh@swivel:~$ sudo btrfs fi usage / O
kup if it's worth backing up, so
you shouldn't really need to worry about that step unless you want to
freshen up your backup, and can simply do the mkfs and restore steps.
Depending on how deep into -musage= and -dusage= you have to go, and how
long it takes on your spinning rust, it
e being before the earliest supported 3.18 LTS
kernel, let alone comparable to your current 4.2 kernel or the 4.4 LTS
upgrade or 4.1 LTS downgrade that would be recommended on the LTS track,
or 4.4 or 4.5 on the current track.
--
Duncan - List replies preferred. No HTML msgs.
"Every n
way, apparent typo:
s/Node code/No code/
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this list: send the line "unsubscribe
he data=writeback
default that got reiserfs its bad stability reputation) it has in my own
experience been incredibly stable, even on systems with hardware issues
that made most filesystems (including a then much less stable and mature
btrfs) unworkable.
--
Duncan - List replies preferred. No HTML m
Jose Otero posted on Mon, 28 Mar 2016 22:30:56 +0200 as excerpted:
> Duncan, you are right. I have 8 GB of RAM, and the most memory intensive
> thing I'll be doing is a VM for Windows. Now I double boot, but rarely
> go into Win, only to play some game occasionally. So, I think I&
in the first place.
> Do any devs do regular regression testing for these sorts of edge cases
> once they come up? (i.e. this problem won't come back, will it?)
As should (now) be obvious from the above, yes, definitely. Most patches
to specific bugs also include fstests (originall
r*-based mechanisms. I'd certainly imagine the
Snowden's of the world will be doing that sort of thing, among the
multitude of security options they must take.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the
ward increasing btrfs
raid1 robustness and will definitely be a noticeable step on the journey
toward production-ready, for sure, and now that you've nailed it down so
nicely, a fix should be quickly forthcoming. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program
says always swap out instead of
dumping cache; set to 0 it says always dump cache to keep apps from
swapping; the default is normally 60, IIRC.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master.&qu
simply
curious and read some developer-targeted stuff anyway, even if you don't
claim to actually be one.
---
[1] Single-device suspend-image: There are ways around this that involve
complex hoop-jumping in the initr* before the image is reloaded, but at
least here, I prefer to avoid that
Martin Steigerwald posted on Sun, 27 Mar 2016 14:10:07 +0200 as excerpted:
> On Freitag, 4. März 2016 12:31:44 CEST Duncan wrote:
>> Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
>> > 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>>
Henk! I'll have to remember this as it's
a very clever and rather useful method-tool to have in the ol' admin
toolbox (aka brain). =:^)
I only wish I had thought of it, as it sure seems clear... now that
you described it!
Greatly appreciated, in any case! =:^)
--
Duncan - L
eady be applying it to their shipped versions as it's certainly a fix
worth having.
I'll simply refer you to previous discussion on the list for the patch,
as that's where I'd have to look for it if I needed it myself before it
gets mainlined.
--
Duncan - List replies pre
u build a kernel with those patches to see if that alone
fixes it, before possibly having you try various debugging patches to
hone in on the problem, if it doesn't, so he can hopefully duplicate the
problem himself, and ultimately come up with a fix.
--
Duncan - List replies preferred. N
trouble, either of the backup if you knew the risk, or of the
research to know the risk in the first place. Thus, you can be happy at
saving that hassle which you defined to be of more value than your data,
even if the data itself ends up being unrecoverable.
So either way you save what was of
o in the commit comment... What filesystems
other than btrfs allow DUP? =:^) It's correct in the posting subject.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
those
backups, then by definition it's not worth the hassle, and starting over
with a fresh filesystem is all three of (1) less hassle, (2) a chance to
take advantage of newer filesystem options that weren't available when
you first created the existing filesystem, and (3) a clean star
e, but I'd hope it'd only appear
sometime later, after another device upgrade or two, at least.
Of course, that's assuming it's either this bug, or another one that's
fixed by starting over with newly created filesystem with all currently
intended devices included in t
ll
userspace does is call the appropriate kernel code to do the actual work.
So the problem here is almost certainly kernel.
Meanwhile, I have an idea of what /might/ be your balance problem, but I
want to cover it in a separate reply. Suffice it to say here that the
news isn't great, if this
evice-path
blacklist, because device paths are routinely symlinked.
I guess that's obvious from a kernel dev perspective, but perhaps not so
much from an admin-user perspective, where the device-path /is/ often
considered the device.
--
Duncan - List replies preferred. No HTML msgs.
&
e Problem
FAQ is the first one that occurs to me) in the btrfs wiki could be quite
useful, to many.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe
ng than the other, fixes to one might not carry over to the other,
etc.
Tho as you suggest, possibly with a transition period during which both
implementations are available, to work out any differences in results and/
or dramatically worse runtime cases.
Thanks. =:^)
--
Duncan - List replies pref
ity. Either a still stabilizing filesystem like btrfs works for
them and they don't need code that mature and stable after all, or they
probably shouldn't be using btrfs in the first place.
Which again is where that research I mentioned above comes in... if their
data is valuable enoug
snapshot, there. You need a backup to recover
in that case.
Similarly in the case of an electrical problem, robbery of the machine,
or fire, since both/all devices in a raid1 will be affected together. If
you want to be able to recover your data in that case, better have a real
backup, prefe
ll.
So please update to a 4.1 kernel or so, and a similar userspace, try
again, and see if you still have the problem. Alternatively, if you're
relying on your distro for support, rely on your distro, as we'll do what
we can to support older versions here, but when there's prob
ood ideas, it
might take quite some time (over five years) to actually be implemented.
So don't get your hopes up for anything too immediate, or even
intermediate term (2-5 years out), unless you get extremely lucky and the
devs see it as a way to implement something they already are worki
ary to get up to
speed with the code and can work with the other devs in terms of timing,
etc. But that will definitely take significant time even if you do it,
and the alternating backup solution can be put to use as soon as you can
get another device plugged in and setup. =:^)
--
Duncan - List r
dereference symlinks before doing this check?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs
(Of course, the wiki has a short user-targeted description of what
changed in each btrfs-progs release as well, and I could look it up there
if wanted to, but so can you, and I'm using the older raid1, not parity-
raid, so I don't have the direct personal interest in that info that
privately if you'd like. Tho if you're familiar at all with news and
have a client to use on news.gmane.org, or simply have lynx around and
can follow the link above in it, you can find and grab the news article
for yourself.
--
Duncan - List replies preferred. No HTML msgs.
&quo
s.
The --force requirement for -s /does/ encourage people not to touch it at
all, separately, and there could be very good reasons to normally treat
system as metadata and process them as a combined unit, but even then, it
seems very odd to me to expose -s on its own, even if --force is
requir
t this is
precisely the information that btrfs send -p provides. If you can strip
the changes themselves out and what's left is either human readable or
can be processed to human readable, then it should be exactly what you're
after, the changed blocks, for data and metadata both.
--
Once you have all those extra data and metadata chunks
removed, you can shrink the filesystem, then the partition it's on, and
let the ssd firmware have the now unpartitioned space. Only thing is I
don't know a tool to actually trim the now free space, and am not sure
whether btrfs resize
Ole Langbehn posted on Fri, 18 Mar 2016 10:33:46 +0100 as excerpted:
> Duncan,
>
> thanks for your extensive answer.
>
> On 17.03.2016 11:51, Duncan wrote:
>> Ole Langbehn posted on Wed, 16 Mar 2016 10:45:28 +0100 as excerpted:
>>
>> Have you tried the autodef
at I rebooted, and I attributed the one-off to something
else. But with no other attributes indicating issues, I remain clueless
as to what might have happened and why that 1-worst, particularly so
given the 0 threshold for that attribute and that it's an old-age
indicator rather than a fa
al good or to stay away from, in
ordered to narrow down the search a bit, so this was really helpful,
particularly the Crucial bit as I already know Intels aren't
realistically in my price range.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a mas
Pete posted on Fri, 18 Mar 2016 18:16:50 + as excerpted:
> On 03/18/2016 09:17 AM, Duncan wrote:
>> So btrfs raid1 has data integrity and repair features that aren't
>> available on normal raid1, and thus is highly recommended.
>>
>> But, raid1 /does/
above and try there, reporting appropriate
version numbers if the problem still exists, or ask your distro for the
support it offers on btrfs on older code, if indeed it does offer that
support.
As I said, only extremely limited and general help, not specific to your
problem at all, but it'
of
dupe are surely why I have such a personal negative reaction to dedupe.
But precedent and current usage being what they are...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richar
pete posted on Mon, 14 Mar 2016 23:03:52 + as excerpted:
> [Duncan wrote...]
>>pete posted on Sat, 12 Mar 2016 13:01:17 + as excerpted:
>>>
>>> Subvolumes are mounted with the following options:
>>> autodefrag,relatime,compress=lzo,subvol=>
&
ure if you didn't write what you actually intended, or if either you or
I misunderstood something somewhere along the line.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard S
Marc Haber posted on Sun, 13 Mar 2016 22:05:37 +0100 as excerpted:
> On Sun, Mar 13, 2016 at 05:12:35PM +0000, Duncan wrote:
>> Marc Haber posted on Sun, 13 Mar 2016 12:58:10 +0100 as excerpted:
>> > I see the same metadata spread as with the old filesystem in btrfs fi
>&g
y case. If you know your ssd isn't one of the
deduping ones (as I do, here), you can of course overrule that by
specifying modes at mkfs.btrfs time.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is you
the filesystem away after I recovered what I needed, even if
it did appear to work successfully.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from t
akes little sense to me either. So only because
it's already in use in kernel code, but if this /were/ the original
kernel code...
So I definitely understand your confusion, Qu, and have the same personal
preference even as a native English speaker. =:^)
--
Duncan - List replies preferred
backup yet, until that verification is done), just in
case, and then even in the worst-case scenario, btrfs check --repair
can't do more than inconvenience you a bit if it makes the problem worse
instead of fixing it, since you have current backups and will only need
to blow away the f
all full-speed data
limits, I can't switch to cell for data, and it's simply not cost
effective for voice when I can get full US phone coverage at no
additional cost for what amounts to $2.50/mo.).
But FWIW, if you've not already discovered it, plug in phone autocorrect
on youtube
ssues.
Which is definitely another reason not to consider btrfs fully
stabilized, until that sort of thing gets sorted. Personally, I'd say
just require superuser privs (and/or appropriate filecaps and/or SEL
security labels) to create them as well, and avoid the whole problem.
Yes, it'l
d with the crypto patches.
Call me a conspiracy nut, but don't be too surprised if someone's
introducing some product with btrfs and encrypted subvolumes a year or 18
months from now... I know I won't be! =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree progr
e in say 6 months after
that... that means we're looking at 2.5-3.5 years, perhaps longer, for
it. So it's a known issue, yes, and on the roadmap, yes, but don't
expect to see anything in the near (-2-year) future, more like
intermediate (3-5) year future. In all honesty I
serving subvolume
creation to superuser, because that's what's needed for listing and
deletion. Because if not, I fear someone's going to take advantage of it
in some way, perhaps, as with many DoS vulns, using it to deny critical
resources as a way to simplify some other more crit
king and review wording.
Regardless, I believe we've definitely established that while it's in the
mainline kernel and is no longer experimental, there's still quite some
warning there, contrary to Mark Habor's claim otherwise. And indeed, if
following that warning literally,
east
to me, which makes it a new and interesting bug. But not being a dev,
that's about as far as I can take it. As CMurphy said, file a bug with
all the various information, and hope the devs can replicate and trace it
down.
--
Duncan - List replies preferred. No HTML msgs.
"Every
han it should, and if that change in the number of devices is due to a
device failure, that means a window during which additional device
failures isn't covered also 10 times longer than it should be. Not good
for the life of your data, for sure!
--
Duncan - List replies preferred. No H
tadata such as
ownership/perms/times, and symlinks, if you wish.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this list: send the line
fix, and might well appear to work fine for awhile, until BOOM!
If there's a chance the filesystem in question was created by that bugged
mkfs.btrfs, don't even try to fix it, just get what you can off it and
recreate with a mkfs.btrfs without that bug, ASAP.
--
Duncan - List replies p
sed it myself and I
suspect I'd have to play around with the ranges a bit to figure out what
numbers I should actually be supplying, as the filter descriptions in the
manpage are somewhat vague on this point.
(Anyone who knows where to actually find those numbers to plug in and/or
has
minute commit times
makes sense. But the given reason, a bare wish to reduce writes to the
ssd, without support such as one of the above use-cases or something
similar, really doesn't make sense, at least on its face. I'll agree
with other posters on that.
--
Duncan - List replies pre
AFAIK it should be in 4.5, which is getting close to release, so if
you prefer to run 4.5-rcX to applying the patch yourself, that should
work as well.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he i
Nicholas D Steeves posted on Thu, 03 Mar 2016 16:21:53 -0500 as excerpted:
> Hi Duncan,
>
>> Of course either way assumes you don't run into some bug that will
>> prevent removal of that chunk, perhaps exactly the same one that kept
>> it from being removed durin
Dāvis Mosāns posted on Thu, 03 Mar 2016 17:39:12 +0200 as excerpted:
> 2016-03-03 6:57 GMT+02:00 Duncan <1i5t5.dun...@cox.net>:
>>
>> You're issue isn't the same, because all your space was allocated,
>> leaving only 1 MiB unallocated, which isn't nor
u're forcing sub-4K writes to storage at high priority so fast
they have little chance to be consolidated into whole 4K block writes.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Ric
ecommendation now that previously, even if it's still tempered
with "but keep up with the list discussion and current on your kernels,
and be aware there are still occasional corner-cases being worked out" as
a caveat, which it should be said, is only slightly stronger than the
general rec
one or the other is out of sync with your needs.
And if you find the distro's provision of btrfs support on that old a
kernel sufficient, then you probably should be looking to your distro
/for/ that support, as well, not here, as the level of support we can
provide on such old kernels, p
ilar being posted to the list. But it does say zero usage,
so by logic, either of the above balance commands should just remove it,
actually pretty fast, as there's only a bit of accounting to do to remove
it. And if they don't, then it /is/ a bug, but I'm guessing they will.
=:^)
the bug refuse
to allocate more, resulting in ENOSPC errors even when there's tens or
hundreds of GiB of unallocated space, where you had only that 1 MiB.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your maste
asonable quota stability?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
Austin S. Hemmelgarn posted on Wed, 02 Mar 2016 08:43:17 -0500 as
excerpted:
> On 2016-03-01 16:44, Duncan wrote:
>> John Smith posted on Tue, 01 Mar 2016 15:24:04 +0100 as excerpted:
>>
>>> what is the status of btrfs raid5 in kernel 4.4? Thank you
>>
&
, /regardless/ of the
filesystem and hardware that data is on. =:^)
And with it either backed up or of only trivial value regardless, you
don't have anything to lose, and even if raid56 mode /doesn't/ prove so
stable for you after all, you can still rest easy knowing you aren't
going t
ago, well over a decade) and which I still use occasionally to look
up files I don't have installed, as here, says lxc-ls is part of the lxc
package, so that esearch candidate was correct. =:^)
So, umm... while I'm not a doctor, perhaps making or keeping that
appointment with your shrink
#x27;t have that problem
to worry about. =:^)
Oh, and btrfs quota management exacerbates the scaling issues
dramatically. If you're using btrfs quotas, either half the max
snapshots per filesystem recommendations, or reconsider whether you need
quota functionality and turn it off, elim
Γιώργος Πάλλας posted on Sun, 28 Feb 2016 10:17:38 +0200
as excerpted:
> On 28/02/16 05:45, Duncan wrote:
>> Γιώργος Πάλλας posted on Sat, 27 Feb 2016 13:45:03 +0200
>> as excerpted:
>>
>>> Hi all.
>>>
>>> If I have a btrfs subvolume 'subv
if it's "the way
you like it, it!" for you. =:^)
FWIW the fstab (5) manpage is the official documentation for it, but it
says effectively what I said above. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use
r maybe it's simply a comment reserving
the -r option?), but it doesn't work yet.
However, it shouldn't be horribly difficult to hack up scripts that
automate the otherwise manual recursive-send/receive for you, as I'd very
likely do myself if I needed that functionality.
ystem more appropriate to your stability
and support needs, which wouldn't be btrfs, as it's simply not a
recommended choice, at least here on-list, if you're not planning to keep
to the recommended last two kernel release series of either current or
LTS.
--
Duncan - List replies
501 - 600 of 1873 matches
Mail list logo
