Hi,
I have an element of doubt that someone may be able to clear up for me.
I have a Reiser3 volume /home from a SUSE 10.1 system. I removed the drive and rebuilt a SUSE 11.0 system on a new and larger disk. I now require to attach the old drive, mount the old /home filesystem (Reiser3) under /home/recovery, so will have /home/recovery/home. . .

If I mv subordinate Reiser3 directory structures into the EXT structure, am I safe to assume that the OS will handle the structure changes ok?

I have in the past experienced minor problems copying/moving Reiser3 directories to a fat32 memory stick when things become corrupt and unusable. Transferring individual files is OK, but the directory structure seems to cause problems because of structure incompatibilities.

Thanks in anticipation

I did a backup from a mounted nfs partition recently before pulling a hard drive that was going bad. I used several steps however using tar. In my experience, for very large transfers (> 100G) it is better to do it in stages in case something goes wrong. My example here should work in one go however.

This assumes that the usernames are the top level directories under the old /home partition. If not,
I would recommend that you mount the old home partition under /mnt/ however so that the old home isn't in the new home's directory structure.

The -v argument is optional. It just prints out the filenames as they are being copyied over.

Here is a third example where I transfered a directory from one computer to another. You could do this to transfer /home to a new computer for example: This copies hpmedia:work to qosmio:newwork, and was tested. I use public key authentication and my private key (on the qosmio host) is protected with a passphrase. This is the reason for the ssh-agent and the ssh-add commands. They allow you to ssh into a server without needing to reenter your passphrase.
You could use this to transfer a directory or mounted partition over the Internet, as long as you can ssh into the old computer.

Postscript:
Just to confuse the matter more, it would have been better if I didn't want to delete my ~/work directory in qosmio:. I would have used
ssh hpmedia tar -cf - work | tar -C /home/jschiwal -xvf -

I ended up with /home/jschiwal/newwork/work. Using the entire directory as the source ensures that your file arguments includes hidden files and directories.
These commands may be better run as root in case a file uses different ownership.

note 2:
delete the /home/<username>/.thumbnails directories. There could be a massive number of files in there. Also consider removing or renaming /var/cache/<username>/beagle/. It may contain thousands of items and copying on the same machine, you could be trying copy from the same source to the same destination, via soft links in ~/.kde ( if you are using .kde ).

note 3:
If the usernames are the same, and the old drive is on the same system as the new one, consider what the implications of symbolic links in hidden directories are. I don't think you want to follow links in this case because the source and target would refer to the same file, as in the case of files in /var/cache/kde-<username>/. If /tmp and /var/cache and /var/tmp/ are located on a different filesystem, then you want to follow the link and archive/restore the file. If they are on the same filesystem, you might want to do so if the files are new but not if the file is present. Reading through the tar info manual for link and overwrite options may be a good idea.

note 4:
Clearing files in /tmp/ before restarting the computer could eliminate a lot of garbage being transfered if you follow links. Not following links however could cause problems with KDE or GNOME. Stale .pid files could cause a problem trying to log into KDE or Gnome. Be careful you don't tork up the ownership and permissions of files.

Generally, it would be a good idea to remove as many cached items as ~/.icons. The problem with .thumbnails is both the size of the hidden subdirectory and the huge number of files in it which aren't needed. The same for /var/tmp.

note 5:
Take a look with:
find ./.[^.]*/ \( -not -user <username> -o -not -group <usergroup> \) -printf '%u:%g\t%p\n'

You may find items owned by a service that is linked to from a hidden .kde or .gnome directory. If you are replacing the entire system, there are items owned by you in /tmp (which can be ignored) and /var/. When I did this I found files owned by "users", which I promptly fixed. (SuSE uses "users" as the default group) I made the change latter but missed some files. You want to use "find" to find directories owned by you in /var/. Some of the subdirectories you find may be owned by a system user such as "beagleindex" for example. For the kerry beagle files, you might decide not to copy them to a new system. There are just too many of them and many are for system files which may be wrong for a new system. For example, I add /usr/share/doc and /usr/src to beagle search so that documentation and source files are indexed.

Good Luck. I hope I haven't confused you too much.

Hi Jshiwal,

Thanks for the good advice. Forgive my delay in responding, but I have had a rather busy day. The only issue I had was the uncertainty with the change in filesystem types, the uncertainty principle growing from very small issues to make me excessively cautious. There is no network involved and the volume had around 15Gbyte used with around 80% occupancy so due for an upgrade before my hand was forced. Now the disk has forced the issue.

The affected volume was /home and the remainder of the original SUSE 10.1 system is entirely expendable. The system was/is a personal box with two users, the primary has data and the other user was created as part of a test and left to languish thereafter.

I understand your concern about using one large tar file agree that there is no reason to tempt fate. My plan was to mount the old /home directory as /mnt /home/. My *mount* homework is still to be done to ensure that my understanding is brought up-to-speed and practiced a couple of times. Never a strong point as I use the command so very infrequently.

My intention is to cherry-pick the directories under /mnt/home/user1 and move them individually; there can be numerous sub-directories hence my original concern. A quick inspection of the hidden directories reveals nothing that I need to preserve but a few hidden files that might be worth preserving, just-in-case largely because I may have parked them to reduce visible clutter.

From /home/user1Pulling a group of directories from the doubtful disk direct to the new system. Extraction from and deletion of the tar files can be done progressively. I used to use tar on Solaris The tar volumes were large and the disk space required a bit of managing as they were processed.


I admit to not being totally conversant with your particular use of pipes with tar, but I will set up something safe and do a bit of investigating to familiarise myself.


The only other files that might be of interest are bookmarks under Firefox, but I think I can sort them. It's just that little niggle that grew out of all proportion in my mind.


Have you ever come across a configuration question and backed away from it numerous times until you had really convinced yourself that you understood the selection you were making was the only logical one? I just wasn't sure I could back away safely, so needed that reassurance.


I appreciate your taking the time to assist and and thank you for your wisdom. I'm probably also on the way to learning a little more about tar that I hadn't explored previously.

File ownership isn't likely to be an issue.

Regards,

The Reiserfs is built on the ext filesystem. You may have more issues in what options are enabled on each filesystem, and what version of the filesystem you are using, than in the two filesystems being different. AFAIK, both have support for ACLs and quotas, however one or the other may not have had them enabled. If you don't use acls, extended attributed or quotas on your home partition, you don't need to worry.

ACLs are used by PackageKit to control access to devices. Your main filesystem needs acl support. For example, to enable you to use a pendrive as a regular user, it sets an acl on the partition. It doesn't change the ownership of the entire device as is sometimes done.

The fat32 filesystem of a pendrive doesn't support any of the permissions, ownership, acls, extended attributes, or quota support that Linux uses. You can use tar or star to archive the files into a single file. When extracted you can preserve ownership. Older versions of tar didn't support extended attributes, but if you have a newer distribution, it should, if you use them. Check your documentation to be certain.

If you use Fedora Core, make sure that the security attributes that selinux uses are supported by your backup program.

Good Luck. There isn't any problem mounting your old home partition and cherry picking what you to restore.

No ACLs on either system unless SUSE11.0 snuck them in, a bit like the Firefox cookies are now contained in an sqlite database rather than a flat file. New system so a good time to see what's appearing when most cookies are refused. If prompted I usually refuse as a matter of course and see what fails to work properly. Surprisingly little as it happens, but it doesn't hurt to weed out some of the unrecognised ones. Obviously a lot easier on a freshly built box.

It wouldn't surprise me if Firefox bookmarks had gone the same way, but it's all a good learning exercise and most of the bookmarks are hot on the day but often slip into disuse as time passes and more pressing projects subtly change the focus to new areas of endeavour.

Reiser3. I didn't know that it was based on EXT3. I believe that one of the reasons for SUSE deprecating the use of Reiser FS, which used to be the default in 10.1, was that support became less certain when Herr Reiser was banged up accused of murdeing his wife - I believe. I also understand that he was very clever, but not so much a persons person - something that could be overlooked, perhaps as personal disposition doesn't stop technological colaboration, but lack of a phone and email facilities just might be seen as a show stopper in the ongoing development and confidence department!

Pendrives, yes I have a couple that I have managed to clobber, one an 8GB stick on it's second outing. I decided to copy a SUSE iso to it and all seemed to be going swimmingly until it choked and croaked. a dd zero candidate when I can lay hands upon it. You guessed I put it safe in the back of a drawer - somewhere - probably a drawer full of junk that is difficult to get at properly because of the gear in, on and around it.

As soon as I can arrange some convenient (multifaceted word includes references to apathy and line-of-least-resistance and prevarication among others) PC down time I will sort out the old disk and crack on with the job.

Meanwhile it's coming up breakfast time and I should get my head down to prepare myself for the day ahead. At almost 6am, it's not going to be an early start for sure. Frosty outside too I need the sun to come up and melt the ice on the windscreen and give the frozen locks a chance - why don't they put WD40 access holes to lube the mechanism so they don't fail so frequently. It makes me irritated that the manufacturer, think 'lemon', is aware of the problem and churns out the same lock mechanisms knowing that they are expected to fail after about 3 years. I get worried when they start selling them on bandoliers.

Thanks again and a very good night to you.

I think that Reiserfs was built on early ext2, and that it's purpose was to introduce journaling. Both ext3 and reiserfs are slower but more robust, and thus more suitable for workstation usage, in case of improper shutdown.

The decision to stop Reiserfs development was made before Reiser's crime. The reason given was that support was lagging in Reiserfs bug fixes than ext3. It may have been actually a cost saving measure. The Mr. Reiser was difficult to work with, and the kernel developers have problems with how some things are implemented. AFAIK, object based ReiserFS V4 has been in development for years and SuSE may have felt that development wouldn't go forward fast enough.