Re: [4.3-rc4] scrubbing aborts before finishing (SOLVED)

2015-12-17 Thread Martin Steigerwald
Am Mittwoch, 16. Dezember 2015, 00:18:53 CET schrieb Martin Steigerwald: > Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > > > Am

Re: Ideas on unified real-ro mount option across all filesystems

2015-12-17 Thread Karel Zak
On Wed, Dec 16, 2015 at 09:15:59PM -0600, Eric Sandeen wrote: > I have always interpreted it as simply "no user changes to the filesystem," > and that is clearly what the vfs does with the flag... Yep, > Given that nothing in the documentation implies that the block device itself > must remain

Re: need to recover large file

2015-12-17 Thread Langhorst, Brad
I have updated the btrfs tools. The error with find roots was fixed. I think i’m making some progress… sudo ./btrfs restore -v -o -t 25606820544512 --path-regex ^/\(\|deer\(\|/masurca\(\|/quorum_mer_db.jf\)\)\)$ /dev/sdd1 ~/recover/ parent transid verify failed on 25606820544512 wanted 21614

ERROR: scrubbing failed for device id 1: ret=-1, errno=28 (No space left on device)

2015-12-17 Thread Christoph Biedl
Hello, checking all my btr file systems after seeing a lot of trouble on a particular installation, I came across this: # btrfs scrub start -B -c3 /mnt/schroot/ ERROR: scrubbing /mnt/schroot/ failed for device id 1: ret=-1, errno=28 (No space left on device) scrub canceled for

Re: Ideas on unified real-ro mount option across all filesystems

2015-12-17 Thread Eric Sandeen
On 12/17/15 8:01 PM, Christoph Anton Mitterer wrote: > On Fri, 2015-12-18 at 09:29 +0800, Qu Wenruo wrote: >> Given that nothing in the documentation implies that the block >>> device itself >>> must remain unchanged on a read-only mount, I don't see any problem >>> which >>> needs fixing.

Re: Ideas on unified real-ro mount option across all filesystems

2015-12-17 Thread Christoph Anton Mitterer
On Fri, 2015-12-18 at 09:29 +0800, Qu Wenruo wrote: > Given that nothing in the documentation implies that the block > > device itself > > must remain unchanged on a read-only mount, I don't see any problem > > which > > needs fixing.  MS_RDONLY rejects user IO; that's all. > > And thanks for the

Re: attacking btrfs filesystems via UUID collisions?

2015-12-17 Thread Christoph Anton Mitterer
On Thu, 2015-12-17 at 03:25 +, Duncan wrote: > So it's definitely _not_ something that reiserfsck would do in a > "normal"  > fsck, only when doing "I'm desperate and don't have backups, go to > the  > ends of the earth if necessary to recover what you can of my data, > and  > yes, I

Re: [auto-]defrag, nodatacow - general suggestions?(was: btrfs: poor performance on deleting many large files?)

2015-12-17 Thread Christoph Anton Mitterer
[I'm combining the messages again, since I feel a bit bad, when I write so many mails to the list ;) ] But from my side, feel free to split up as much as you want (perhaps not single characters or so ;) ) On Thu, 2015-12-17 at 04:06 +, Duncan wrote: > Just to mention here, that I said

Re: Ideas on unified real-ro mount option across all filesystems

2015-12-17 Thread Qu Wenruo
Eric Sandeen wrote on 2015/12/16 21:15 -0600: On 12/16/15 7:41 PM, Qu Wenruo wrote: Hi, In a recent btrfs patch, it is going to add a mount option to disable log replay for btrfs, just like "norecovery" for ext4/xfs. But in the discussion on the mount option name and use case, it seems

Re: Ideas on unified real-ro mount option across all filesystems

2015-12-17 Thread Christoph Anton Mitterer
On Thu, 2015-12-17 at 20:51 -0600, Eric Sandeen wrote: > >   -r, --read-only > >    Mount the filesystem read-only.  A synonym is -o ro. > > > >    Note  that,  depending  on the filesystem type, state and > >    kernel behavior, the system may still write to the > > device.  For > >