10 issues, but they're amdgpu, not btrfs related. (Unfortunately,
between working long hours and being sick partly as a result, I've had
little time to report them, but booting with amdgpu.dpm=0 has let me
continue running 4.10-git, tho I don't know exactly why if I'm not going
y
> machine find took an huge quantity of memory (up to 3GB) when used by
> updatedb.
FWIW, I saw it (via news.gmane.org list2news service) here. It's well
over my head, tho, so I didn't reply, but I found it interesting.
--
Duncan - List replies preferred. No HTML msgs.
&qu
even predict, at
this point.
But I do know all about waiting, by now. I've learned, and am continuing
to learn, all about patience! =:^]
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your m
;s going to take awhile, and you'll be much happier with btrfs in the
mean time if you don't have them enabled.
--
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
that may be inappropriate to your
needs. They just don't seem to be a particularly good match, at least
for the general case. That isn't to say it's the /wrong/ choice for your
particular use-case, but it's worth considering a reevaluation to be
sure, if you haven't
Austin S. Hemmelgarn posted on Thu, 02 Feb 2017 07:49:50 -0500 as
excerpted:
> I think (although I'm not sure about it) that this:
> http://www.spinics.net/lists/linux-btrfs/msg47283.html is the first
> posting of the patch series.
Yes. That looks like it. Thanks.
--
Duncan
Graham Cobb posted on Thu, 02 Feb 2017 10:52:26 + as excerpted:
> On 02/02/17 00:02, Duncan wrote:
>> If it's a workaround, then many of the Linux procedures we as admins
>> and users use every day are equally workarounds. Setting 007 perms on
>> a dir that doesn&#
making the same assumptions that
everyone else does, that an admin knows what they are doing and sets the
upstream permissions with that in mind. If they don't, how is that
btrfs' fault?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a
Adam Borowski posted on Wed, 01 Feb 2017 12:55:30 +0100 as excerpted:
> On Wed, Feb 01, 2017 at 05:23:16AM +0000, Duncan wrote:
>> Hans Deragon posted on Tue, 31 Jan 2017 21:51:22 -0500 as excerpted:
>> > But the current scenario makes it difficult for me to put redundancy
>
7;t have enter access to the parent, you can't read/write the
child, thus no need for btrfs-receive specific permission-hoop-jumping.
(And of course SELinux or similar could be used to tighten permissions
even further, should that be justified by the use-case.)
--
Duncan - List replies pref
trivial value by
the inaction of not having that backup while running a filesystem known
to be still stabilizing, didn't you?
Otherwise, run a filesystem more appropriately stable and mature
according to your needs, as btrfs in its current state apparently doesn't
meet those needs.
ation as a result.
This sort of additional sync guarantees may be in the final generally
considered stabilized product, but that's yet some time (years) away.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the
ormal path.
IOW, it should be a great help to users that don't know btrfs command or
filesystem internals very well, and/or who don't find regex use
particularly easy.
IOW, it'd be an excellent tool to either include in btrfs-tools as-is or
C-codify and add as a btrfs subcomman
.
Or at least it's supposed to. I've never actually used it, tho I have
examined the script out of curiosity to see what it did and how, and it /
looks/ like it should work. I've kept that trick (and knowledge of where
to look for the script) filed away in the back of my head in
fs / didn't, because the xfs, while potentially damaged a bit,
didn't suffer the abuse of writes to the wrong device that btrfs may well
have suffered, due to the non-uniqueness of the supposedly universally
unique IDs and the very confused btrfs that may well have caused.
--
Duncan
other device,
selectable via BIOS if necessary, means I may just go ahead and leave my /
boots at 256 MiB each anyway, and just set them both to single mode for
the mixed data/metadata, to make use of the full 256 MiB and not have to
worry about /boot size constraints like I do now with only 128 Mi
,
thereby immediately upping apparent usage. That might explain that
initial jump in usage after the resize. But that's just a WAG. Without
at least btrfs filesystem usage, or btrfs filesystem df plus btrfs
filesystem show, from before the resize, after, and before and after the
balances,
retical, so nothing serious, but now
that it's no longer theory only, it'd still be useful to be able to save
the current version, if it's not /too/ much trouble" type situations,
myself. =:^)
Just don't count on restore to save your *** and always treat what it can
o
was
effectively sacrificial data, known to be potentially eaten by the
testing itself.
--
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 li
he code, as a practical matter it's
probably simply easier to restore from that backup if you valued the data
enough to have one, or simply scrap the filesystem and start over if you
considered the data worth less than the time and hassle of a backup, and
thus didn't have one.
--
Duncan -
ill
shipping instead. And I'm asking in ordered to try to remedy that. =:^)
--
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 lin
hat ancient a long-term-supported
enterprise distro and kernel, presumably you value stability very highly,
which would seem at its root to be incompatible with btrfs' status as
still in development and stabilizing, not yet fully stable and mature.
So a reevaluation is likely in order,
st saved me the trouble (tho I do
need to freshen my backup /boot one of these days, likely testing
mkfs.btrfs on this in the process, but that can wait until 4.10).
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program,
indirectly related to the required size of the system chunk(s), in
ordered to contain the chunk tree supporting all the other chunks,
necessary due not to live data, but due to the snapshots.
Is that a correct read, or is (somehow) that indirect dependency not
there either, despite the system ch
esent, or at least was around 4.8 time,
as I believe that's about when I created the btrfs), be tested and make
it into released code within say five kernel cycles, a year's time?
Obviously I'm hoping so. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every
t
work so well, but then, as I suggested above, if you actually need
quotas, you're best served by using a filesystem where they're actually
stable and work as intended, as well, so in that case, after your backups
are freshened you'll probably be doing a mkfs to some other files
Duncan posted on Thu, 05 Jan 2017 09:23:35 + as excerpted:
> In his case the copying was from 7.2krpm to 5.6krpm drives, but not the
> reverse or when copying from slower to faster.
Ugh. What I /meant/ was:
Slower to faster: worked
Between same speeds:worked
Faster to
sctl config. Look in /etc/sysctl.d/* and/or /etc/sysctl.conf, as
appropriate to your distro.
[3] Approaches: The memory figure used for calculating this percentage
excludes some things so it won't actually reach 10% of total memory. But
the exclusions are small enough that they can be
tarting over again, as there's
a real question as to whether it can even be properly fixed, tho I'm not
sure it will come to that.
--
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."
counting on that, I'll have a problem that
restore can't fix, so I really do consider those backups a measure of the
value I place on the data, and would be stressed to a point, but only to
a point, if I ended up losing any changes between my sometimes too stale
backups, and my
btrfs
is the right filesystem choice for you, because it /isn't/ yet fully
stable and mature, and chances are you'd be better off with a more stable
and mature filesystem where not having updated at-hand backups is less of
a risk (altho as I said any sysadmin worth the name will tel
Christoph Anton Mitterer posted on Thu, 29 Dec 2016 04:43:35 +0100 as
excerpted:
> On Mon, 2016-12-26 at 00:12 +0000, Duncan wrote:
>> By themselves, free-space cache warnings are minor and not a serious
>> issue at all -- the cache is just that, a cache, designed to speed
>&
is triggered that would likewise show up in other situations with a
similar amount of data/metadata written), there should be no effects
outside that received subvolume.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the
edia
corruption, blocks not matching their checksum, while check deals with
filesystem logic errors, whether or not the blocks containing them match
the checksum.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program,
avior isn't really a factor at the
btrfs level as that's the transfer layer and btrfs isn't worrying about
that, simply assuming it to have the necessary reliability.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use
off and rewrite at least the boot-
critical stuff to decompress it, so as not to be affected.
--
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 fro
ated out of
active use and are no longer being actively rewritten/appended. They
don't /want/ further modifications compressed to the same level in real-
time.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the progr
it more time trying to save it,
successfully in my case, once I knew I was actually in the recovery or
loss situation.
Tho in your case it looks like you are looking at the warnings before it
gets to that point, and it's both a backup already, so you presumably
have the live data in most c
that's beyond me. So while it's
quite possible someone else will recognize a specific bug and be able to
point you toward a specific fix, tho honestly I don't expect it for
something as old as what you're posting about, general list-recommended
upgrades and alternatives f
btrfs ignore the given number if all chunks (both copies in raid1/10
mode) appear to be accounted for on already available devices.
I believe the patch has been queued, but isn't in a release yet.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lo
Stefan Priebe - Profihost AG posted on Mon, 05 Dec 2016 12:12:12 +0100 as
excerpted:
> isn't there a way to move free space to unallocated space again?
Yes, btrfs balance, but...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
a
isn't showing any shared, since
it's mounted with compress=lzo as well.
--
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 l
Marc Joliet posted on Sun, 04 Dec 2016 20:20:51 +0100 as excerpted:
> On Sunday 04 December 2016 18:24:08 Duncan wrote:
>> Marc Joliet posted on Sun, 04 Dec 2016 17:02:48 +0100 as excerpted:
>> > [After trying it]
>> >
>> > Well, crap, I was able t
rfs. It
may be possible to make btrfs a bit safer in terms of refusing to mount
and/or going read-only if new devices with the same UUIDs appear in
ordered to avoid corruption, but the basic UUID uniqueness assumption
itself is apparently buried deeply enough in btrfs that it's not goin
I
might suggest you start by testing it. If it fixes the problem for you,
then you can decide whether to try to push it as an upgrade, or try to
bisect the problem further in ordered to properly backport the fix. If
it doesn't, of course the 4.1 and 4.4 LTS kernels are other major test
po
his particular aspect of documentation.
>
> Documentation/mkfs.btrfs.asciidoc | 44
> ---
> 1 file changed, 36 insertions(+), 8 deletions(-)
FWIW, LGTM as a btrfs user and list regular. Thanks. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"E
chunks as necessary to free up some of that allocated
but unused data and metadata space. Then once a suitable amount of space
has been freed, btrfs device remove the temporary device once again, thus
triggering balance to write everything from it back to the original
device once again.
Which i
t's of no
particular value to them anyway, well then, no such preliminary research
and testing is required. Indeed, it would be stupid, because they surely
have more important and higher priority things to deal with.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonf
's purely due to people not understanding the status of btrfs
in general, and that if there's a general deficiency at all, it's in the
lack of a general stability status paragraph on that page itself
explaining all this, despite the fact that the main https://
btrfs.wik
ikis I could in theory edit, as read-only, even if the
alternative is replying repeatedly to list threads such as this, vs. a
single wiki edit. [shrug]
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your mast
Graham Cobb posted on Mon, 28 Nov 2016 09:49:33 + as excerpted:
> On 28/11/16 02:56, Duncan wrote:
>> It should still be worth turning on autodefrag on an existing somewhat
>> fragmented filesystem. It just might take some time to defrag files
>> you do modify, and
assumes COW by default and many of its features
depend on COW -- that's why these features don't tend to be implemented
on conventional rewrite-in-place filesystems in the first place. Both
checksumming and compression are among these COW-dependent features.
--
Duncan - List replies pref
were some worries about performance in some circumstances, and the
option was experimental back then, so it made /sense/ not to have it the
default. But that was then and this is now, and IMO it should be the
default, now. Maybe it will be at some point? But one of the btrfs devs
has to care
x27;t enough on its own to handle it.
Bottom line, the fragmentation is much less of a problem on ssds,
particularly with autodefrag which may well be enough, but as always, it
can be installation and task dependent, so if it's going to be a
production system, do your own testing and make y
Martin Raiber posted on Wed, 23 Nov 2016 16:22:29 + as excerpted:
> On 23.11.2016 07:09 Duncan wrote:
>> Yes, you're in a *serious* metadata bind.
>> Any time global reserve has anything above zero usage, it means the
>> filesystem is in dire straits, and wel
ent files elsewhere, delete
the existing copy, and copy/move them back into place, thus releasing the
old extent references and freeing the space those old extents took.
Of course depending on the circumstances and how your backups are handled
(noting your urbackup.org email address here), it may
btrfs quotas, so being proactive and turning them off if
you don't need them, to avoid having the issues in the first place,
certainly can't hurt.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is y
said, Chris Murphy or
someone else with experience at trying to recover raid56 should be along
with more detail, if you'd still prefer to go to that extra effort
regardless of the real chance it won't help, in case it can.
--
Duncan - List replies preferred. No HTML msgs.
&quo
hardcoded to 128k for compression. Isn't it?
I flagged that as I read it, too, but...
200 KB extents average suggests it can't be compressed, because if it
were they'd be 128 KB extents, not 200 KB. That's a difference of over
half a million extents (128 KB would be ~1.5565 mi
tence for a short sig,
full paragraph for a longer one.
--
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 linu
r the initial setup, or explaining why
the idea won't work, but at this point based on my own understanding, it
seems like it should be perfectly workable to me. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the p
and
patience, and likely a significant level of technical understanding along
with some help from btrfs experts that know more about the btrfs raid56
technical details than I do.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if yo
een reported to do it
for others running into ENOSPC issues. =:^)
--
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 "unsu
Rich Freeman posted on Sun, 25 Sep 2016 09:55:42 -0400 as excerpted:
> On Fri, Sep 23, 2016 at 12:58 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Btrfs raid1 you say, and you have existing compressed files it's trying
>> to read in the backtrace?
>>
>>
ins valid.
The other alternative, of course, is to avoid snapshotting your NOCOW
files (which of course means losing send/receive, since send requires a
read-only snapshot). You can choose one or the other, but can't have
both without one, NOCOW, yielding to the other.
--
Duncan - List re
the kernel
should do dynamically as well, but that's where the bug is as too many
dynamic csum errors trigger a crash even when there's a second copy
available, that scrub later verifies as valid.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has
there, but relatively quite small compared to on-demand per-file defrag.
--
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 &q
ons is a good part of the reason such distros
exist, and a good part of why a lot of people are willing to pay
sometimes rather sizable sums of money /for/ that level of support.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the
are running pretty much correctly, as in that case all
userspace is doing in most cases is calling the kernel to do the real
work anyway, it becomes a much bigger deal when something goes wrong,
because it's userspace code that's executing with btrfs check or btrfs
restore, and
ed
raid1 (unless needed for scrub, etc), not mounting it writable, and as
long as you are careful to do just that, only mount it read-only, you
should be fine.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is y
expected/ to hit 4.8-rc, current development, first. After that, given
that it's already flagged for stable, it should eventually hit all the
stable kernels to which it applies as well. That can be right away, but
if the stable maintainer (Greg K-H, normally) is backlogged due to just
Chris Murphy posted on Mon, 12 Sep 2016 08:48:49 -0600 as excerpted:
> On Sun, Sep 11, 2016 at 10:54 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
>> On the bright side, the double-whammy of being under such tight
>> filesystem size constraints, coupled with finding out yo
Kai Krakow posted on Tue, 13 Sep 2016 00:21:10 +0200 as excerpted:
> Am Sun, 21 Aug 2016 02:19:33 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:
>
>> Chris Murphy posted on Sat, 20 Aug 2016 18:36:21 -0600 as excerpted:
>>
>> > FAT leaves a lot to be
lf of what the size of it suggests it should fit, IOW.
And I think that argument /was/ made, to some extent. But the whole
thing only came up because they found testing with small filesystems
inconvenient due to the mixed-bg default, so rather than fix that by
fixing the tests, they broke th
#x27;m correct, it probably doesn't matter what the compression type
is, only how much of it there is. So compress-force would tend to
trigger the issue far more frequently than simply compress, unless of
course your use-case is a corner-case like my trying to read all those
compressible t
Imran Geriskovan posted on Sun, 11 Sep 2016 21:56:07 +0300 as excerpted:
> On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote:
>> Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as
>> excerpted:
>>>> What is the smallest recommended fs size for btrfs?
the mixed-mode default, despite it
still being extremely strongly recommended for under a GiB.
--
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
trfs is ready for the
first and can in some cases be ready for the second and the third if they
have backups, it's definitely *not* "production ready" for the segment of
the third that don't even have backups.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree pr
e via bios) on another device, I have a 640 MiB btrfs
pair-device raid1 /var/log. It's mixed-mode too, 640 MiB per device, but
pair-device raid1, so I don't have to worry about the 2X data factor on a
single device.
All my other "system" partitions are btrfs raid1 as well
less lucky but still in good shape, they'll fix the root
problem but the balance already got the btrfs so wedged that you'll still
have to mount with skip_balance, then cancel the balance, losing your
place, and then presumably restart a new one.
3) Given the currently active enosp
Austin S. Hemmelgarn posted on Tue, 06 Sep 2016 08:32:02 -0400 as
excerpted:
> On 2016-09-02 06:55, Duncan wrote:
>> Kai Krakow posted on Thu, 01 Sep 2016 21:45:19 +0200 as excerpted:
>>
>>> Off topic: Is ccache really that helpful? I dumped it a few years ago
>>
ows...), I don't know which. And that of course assumes it's even the
same basic bug and would behave as it did for me if you had no snapshots.
That was with kernel 4.7.0 (which I'm still running, I'll be upgrading to
4.8 rcs pretty soon now) I believe. If not, then it w
our actions as
such, regardless of any words claiming the contrary. To the extent that
you can trust your people as much as your backups, great, but not having
those backups really /is/ defining that data as not worth the hassle,
regardless of whether it's lost to malicious attack or to hardwa
Kai Krakow posted on Thu, 01 Sep 2016 21:45:19 +0200 as excerpted:
> Am Sat, 20 Aug 2016 06:30:11 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:
>
>> There's at least three other options to try to get what you mention,
>> however. FWIW, I'm a ge
ing. Of course if they break, you'll
then be dealing with the longer timeouts, but you may find it easier to
simply set that default and deal with the long timeouts on anything else
when and if some other unit does actually break and start following the
longer default timeouts.
--
Duncan - L
less the value of the data simply
isn't worth the hassle, and once you have a backup tested, available and
ready to use should it be necessary, blowing the existing filesystem away
and starting with a fresh filesystem created with the options you want
isn't much more difficult and
filesystem df outputs.
--
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 a
ppened to
the quota code a number of times for instance, as it as turned out to be
a /really/ hard problem, with multiple rewrites necessary, such that even
now, the practical recommendation is often to either just turn off quotas
and not worry about them if you don't need them, or use a m
ou run more or less normally, altho if you try to access whatever file
or metadata the balance is choking on, you'd still be in trouble. And
the results should pin down whether it's the balance, or something else,
triggering the problem.
Beyond that I'll leave for the real expert
these features
are really practical due to cow in the first place, the reason other
filesystems don't tend to have them, and that while there is definitely a
tradeoff to cow vs. nocow, setting nocow doesn't turn off features you'd
have in conventional filesystems anyway, so it's n
device direct from the grub2 prompt, emergency mode if it
can't load the /boot off that device, if you like.
--
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 un
ata cabinet and the
other in another, and lose the connection to everything in the one,
without loss of data as raid0 on the other leg of the btrfs raid1 will
still be operating.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use th
mature than btrfs and offers similar features, plus some
btrfs doesn't have yet, minus a few others as it's an earlier
implementation and some of the stuff learned from it was used when
designing btrfs. So you might look into it and see if it meets your
needs.
--
Duncan - List rep
7;t random and it happens repeatedly in
the degraded area, you're screwed, for whatever file or metadata covering
multiple files it was in, at least. You should still be able to recover
the rest of the filesystem, however.
Which all goes to demonstrate once again that raid != backup, and th
the number of
reported extents, considering it compressed if so. For a few one-off
files, that's easy enough to do manually, but you'd definitely want to
automate the process if you wanted that information on more than a few
individual files.
--
Duncan - List replies preferred.
various countries (China being the one most frequently named) that would
pay good money for unencrypted devices from the right sources.
--
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.&q
et, so for me, I'd either use something other than btrfs, or use
btrfs but really emphasize the backups, including testing them of course,
because I /don't/ really trust btrfs on crypted just yet. But based on
earlier posts in this thread, I admit it's very possible that all the
Chris Murphy posted on Thu, 11 Aug 2016 14:43:56 -0600 as excerpted:
> On Thu, Aug 11, 2016 at 1:07 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> The compression-related problem is this: Btrfs is considerably less
>> tolerant of checksum-related errors on btrfs-compressed dat
ventually make that feature stable and workable for 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." Richard Stallman
--
To unsubscribe from this list: send the line "unsubscribe l
provably exists
a second valid copy, but where this only happens with compression, should
go quite far in stabilizing btrfs on encrypted underlayers.
I know I certainly wouldn't object to the problem being fixed. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfre
301 - 400 of 1873 matches
Mail list logo
