Should I interpret the different used amounts (902.01GB vs 902.03GB)
on my recovered RAID1 filesystem as that not all data is actually
mirrored and so I should run a balance? The devices in the filesystem
below are the same make/model drives.
# btrfs fi show
Label: 'mcmedia' uuid: 92b3345e-2589-423c-a228-d569bf94ab58
Total devices 2 FS bytes used 905.33GB
devid 2 size 2.73TB used 902.01GB path /dev/sdc1
devid 1 size 2.73TB used 902.03GB path /dev/sdb1
Btrfs v0.20-rc1-358-g194aa4a
# btrfs fi df /mnt/media/
Data, RAID1: total=894.00GB, used=892.99GB
Data: total=12.01GB, used=11.56GB
System, RAID1: total=8.00MB, used=132.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=2.00GB, used=1.13GB
Metadata: total=8.00MB, used=0.00
On Thu, Jul 18, 2013 at 10:19 AM, Sandy McArthur <sandymac@xxxxxxxxx> wrote:
> I was able to recover the filesystem using the btrfsck from git (Btrfs
> v0.20-rc1-358-g194aa4a) .
>
> I encourage btrfsck to output a line similar to "Errors found. Run
> again with --repair to attempt repairs." when errors are found.
>
> From using other fsck tools, I expected repairs to be attempted unless
> I specified for no changes to be attempted. This would have saved me
> time and the emotional grief of my perceiving that my problems were
> persisting a btrfsck.
>
>
> On Wed, Jul 17, 2013 at 7:38 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
>> Sandy McArthur posted on Wed, 17 Jul 2013 10:06:05 -0400 as excerpted:
>>
>>> have a btrfs filesystem that is corrupt so that I cannot remove a few
>>> files. Attempting to delete these temp files from before a crash leaves
>>> the filesystem read-only and sends a trace to the syslog. Assistance
>>> correcting this issue is most appreciated.
>>>
>>> I have two disks /dev/sd{b,c}1 to make up this filesystem.
>>> I've updated to the latest btrfs-tools and kernel packages available.
>>> The crash happened with kernel 3.8.13-gentoo.
>>>
>>> # btrfs version Btrfs v0.20-rc1
>>> # [uname -r] 3.10.1-gentoo
>>
>> Hi fellow gentooer. =:^) I'm just a user too so won't attempt a
>> technical answer. However...
>>
>> I see you've tried the latest packages for both kernel and btrfs-tools.
>> That's good as otherwise that's one of the the first suggestion you'd
>> get. However you don't mention the btrfs wiki, nor do you mention trying
>> what it suggests in such cases, so I'll assume you're not familiar with
>> it. (Additionally, being a wiki and btrfs still being under development,
>> it's worth checking back every couple months or so, and possibly using
>> the wiki history function to see what has changed on your pages of
>> interest since your last visit.)
>>
>> Main page (for bookmarking):
>>
>> https://btrfs.wiki.kernel.org/index.php/Main_Page
>>
>> Of course right at the top there it mentions (in bold) that btrfs is
>> under heavy development and to run the latest, which you're basically
>> doing, altho you apparently haven't tried the latest kernel rc or the
>> btrfs-tools git build (which being a gentooer, I know are available, but
>> masked by default). If the following suggestion doesn't help, you might
>> try them, as fixes really are going in all the time.
>>
>> Meanwhile, I recommend reading up on the documentation section of the
>> wiki. In particular, altho with the corruption it may not help in your
>> case, pay attention to the no-space sections of the FAQ and Problem FAQ
>> pages. Even more in particular, when there's space problems it
>> recommends attempting to clobber/truncate a file in place, the idea being
>> to free up space without having to allocate additional metadata space to
>> do it. Again, with corruption it may not help, but it's worth a try.
>>
>> echo > /path/to/file
>>
>> Of course, even more with a development filesystem than ordinarily, you
>> should have good backups, so you shouldn't need to worry too much about
>> finding clobber candidates since you can recover most files from backup
>> in any case.
>>
>> If the echo/clobber doesn't work, try again after mounting with the
>> nodatacow option. But read the wiki for the details.
>>
>> There's also mount options such as recovery (and skip-balance if you have
>> an aborted balance it'd otherwise be trying to restart), that you can
>> try. Of course if you have the space to do so, it might be worth dd-ing
>> the filesystem elsewhere as a backup image, in case you screw things up
>> worse while experimenting.
>>
>> Meanwhile, based on my interested-admin most definitely NOT kernel-dev
>> technical level following of this list at least, there /have/ been recent
>> no-space, extents maintenance and other cleanups in the really-latest
>> code (3.11-rc1+ kernel and live-git btrfs-tools, and there may be further
>> patches posted to the list that haven't actually been committed yet),
>> that may well help in your case. I'm not technically qualified to match
>> backtraces against commits/patches and identify a solid match, but it's
>> definitely worth a try.
>>
>> Finally, as background once you're out of the tight spot, since you're
>> running a multi-device filesystem, you're likely to find the discussion
>> of that on the multiple devices, sysadmin guide, and use cases pages
>> useful. FWIW, here I'm running most of my btrfs filesystems in dual-
>> device raid1 (both data/metadata) mode, to take advantage of the
>> checksumming and extra copy to lookup in case of checksum error, that
>> btrfs offers, in addition to the device-loss scenario that raid1 helps
>> protect against.
>>
>> --
>> 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 message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
