Moving/merging a filesystem back into /

[Charles Marcus]

On 2013-12-03 9:37 AM, Kevin Korb <kmk at sanitarium.net> wrote:
>> Or do I need to specify the filesystem type?
>>
>> mount -t ext3 -o noatime /dev/sda3 /mnt/gentoo/ ?
> I would expect to do this.  Also, you should be converting to ext4 not
> ext3.  In fact, your kernel probably doesn't even have ext3 in it
> anymore.  Standard kernels now use the ext4 code for ext3 mounts.

One thing at a time... ;)

It is working now, and currently has ext3 in the fstab. I'd rather not 
change that at the same time as doing something like this.

> Concerns no. Lack of terror, yes. You will no longer be exposed to an 
> fsck that is almost as destructive as a mkfs

Yes, I've read the horror stories. I've also had this system running for 
8+ years, and had 2 hard resets (and successful fscks) during this time...

There is a lot of FUD about reiserfs.

Not saying it is perfect, or that your concerns are misplaced (my new 
system will use xfs instead), but it isn't as bad as you're making out... ;)

> Nonsense. --numeric-ids disables the ownership translation between 2 
> different systems when rsync is networking. When you are booted from a 
> live environment you still only have 1 user database. It might 
> disagree with the one you normally boot from but you still have only 1 
> so there is nothing to translate.

Ok, well, like I said, since it doesn't matter, that is an argument I 
may pursue later, if I fell a need...

>> Doesn't matter though, since it can't hurt anything, I'll always
>> use it regardless... ;)
>>
>>> ext[34] can remember acl as a default mount option. I have no
>>> idea if reiserfs can do that or not and I recommend against using
>>> reiserfs at all.
>> I know, but this system was built over 8 years ago (when gentoo
>> still recommended reiserfs), and runs like a champ, so no desire to
>> 'fix what ain't broke'... anyway, acls are not enabled on it, so no
>> worries...
> If you ever have an instance where reiserfs needs an fsck you may as
> well reformat and restore.  Reiserfs's fsck just deletes almost
> everything then declares success.  Reiserfs was never recommended
> except for /usr/portage which can always be re-downloaded.  It should
> absolutely never be used for anything important.

Sorry Kevin, this is just plain BS.

When I installed gentoo, it was recommended for things like mail storage 
when you were using maildir (lots of small files)...

And as I said, my experience directly refutes your silly claim that 
"Reiserfs's fsck just deletes almost
everything then declares success".

It has had its problems, and indeed may under certain circumstances be 
more likely to experience unrecoverable damage to the filesystem, but 
most serious problems it has had were fixed fairly quickly (but maybe 
not after lots of people got bit). The fact is ext4 has had its problems 
and horror stories too, just as xfs and every other filesystem out 
there. It is best to stick to verifiable facts when discussing things 
like this.

>> emerge --info shows neither:
>>
>> USE="3dnow acl amd64 bash-completion berkdb bzip2 cli cracklib
>> crypt curl cxx dovecot-sasl dri fam fortran gd gdbm iconv mmx
>> modules mudflap multilib ncurses nls nptl openmp pam pcre readline
>> sasl session snmp sse sse2 ssl tcpd truetype unicode vhosts xml
>> zlib"
> After you finish with this, try adding caps to that.  It is a
> significant security improvement IMO.

Any pointers to docs explaining how/why? I'll google later, but I'm 
curious...

>>> Even on something more dynamic like /home you can still do an
>>> initial copy then update it from the live environment.
>>
>> Ok, so... if I wanted to do this, would I need to add anything to
>> the rsync command on the subsequent run(s)?
> nope.
>
>> So, looks like the command I'll be using:
>>
>> rsync -avHP --numeric-ids /mnt/gentoo/oldusr/ /mnt/gentoo/usr/
> yep.

Cool, thanks again Kevin... :)/**//*
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20131203/c57ef15e/attachment.html>