Re: btrfs convert running out of space

[Marc Joliet <marcec@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]

Am Fri, 23 Jan 2015 08:46:23 +0000 (UTC)
schrieb Duncan <1i5t5.duncan@cox.net>:

> Marc Joliet posted on Fri, 23 Jan 2015 08:54:41 +0100 as excerpted:
> 
> > Am Fri, 23 Jan 2015 04:34:19 +0000 (UTC)
> > schrieb Duncan <1i5t5.duncan@cox.net>:
> > 
> >> Gareth Pye posted on Fri, 23 Jan 2015 08:58:08 +1100 as excerpted:
> >> 
> >> > What are the chances that splitting all the large files up into sub
> >> > gig pieces, finish convert, then recombine them all will work?
> >> 
> > [...]
> >> Option 2: Since new files should be created using the desired target
> >> mode (raid1 IIRC), you may actually be able to move them off and
> >> immediately back on, so they appear as new files and thus get created
> >> in the desired mode.
> > 
> > With current coreutils, wouldn't that also work if he moves the files to
> > another (temporary) subvolume? (And with future coreutils, by copying
> > the files without using reflinks and then removing the originals.)
> 
> If done correctly, yes.
> 
> However, "off the filesystem" is far simpler to explain over email or the 
> like, and is much less ambiguous in terms of "OK, but did you do it 
> 'correctly'" if it doesn't end up helping.  If it doesn't work, it 
> doesn't work.  If "move to a different subvolume under specific 
> conditions in terms of reflinking and the like" doesn't work, there's 
> always the question of whether it /really/ didn't work, or if somehow the 
> instructions weren't clear enough and thus failure was simply the result 
> of a failure to fully meet the technical requirements.
> 
> Of course if I was doing it myself, and if I was absolutely sure of the 
> technical details in terms of what command I had to use to be /sure/ it 
> didn't simply reflink and thus defeat the whole exercise, I'd likely use 
> the shortcut.  But in reality, if it didn't work I'd be second-guessing 
> myself and would probably move everything entirely off and back on to be 
> sure, and knowing that, I'd probably do it the /sure/ way in the first 
> place, avoiding the chance of having to redo it to prove to myself that 
> I'd done it correctly.
> 
> Of course, having demonstrated to myself that it worked, if I ever had 
> the problem again, I might try the shortcut, just to demonstrate to my 
> own satisfaction the full theory that the effect of the shortcut was the 
> same as the effect of doing it the longer and more fool-proof way.  But 
> of course I'd rather not have the opportunity to try that second-half 
> proof. =:^)
> 
> Make sense? =:^)

I was going to argue that my suggestion was hardly difficult to get right, but
then I read that cp defaults to --reflink=always and that it is not possible to
turn off reflinks (i.e., there is no --reflink=never).

So then would have to consider alternatives like dd, and, well, you are right,
I suppose :) .

(Of course, with the *current* version of coreutils, the simple "mv somefile
tmp_subvol/; mv tmp_subvol/somefile ." will still work.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]