[Please keep your replies in standard quoted-context, then reply-in-
context, order. I'm reordering here, but often either don't include
complete context or simply don't bother replying, when it's too much work
to get the reply in the proper context.]
Vladi Gergov posted on Sat, 09 Apr 2016 15:
Anyone know if there is currently with updated kernel and tools a way to
recover the data on this? I have tried btrfs chunk-recovery with not
luck. Anything else I can do to try and get the data off at least?
Thanks in advance!
On Tuesday, 16.11.10 at 16:50, Chris Mason wrote:
> Excerpts from Vlad
Brauchen Sie einen Kredit? Wir bieten Darlehen in 2% gelten heute Kontakt mit
uns auf: legacyassetgro...@hotmail.com
--
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/majord
Well, the message is almost the same after mounting with clear_cache
-> unmounting -> mounting with regular options -> unmounting ->
running btrfsck --readonly.
===
Checking filesystem on /dev/sdb
UUID: 013cda95-8aab-4cb2-acdd-2f0f78036e02
checking extents
checking free
Yauhen Kharuzhy posted on Fri, 08 Apr 2016 22:53:00 +0300 as excerpted:
> On Fri, Apr 08, 2016 at 03:23:28PM -0400, Austin S. Hemmelgarn wrote:
>> On 2016-04-08 12:17, Chris Murphy wrote:
>>
>> I would personally suggest adding a per-filesystem node in sysfs to
>> handle both 2 and 5. Having it o
