Re: ReiserFS + 2.4.4
Ilya Martynov wrote: It is called read-only because user programs that work at level of files and directories can't write on mounted filesystem. Tools that mount filesystem work on lower level. I have visited the web page you pointed out the other day; I have no conclusion (neither did they, and if they didn't, why would I?). BTW, the following is a must read, I believe. I copied it from www.reiserfs.com (the URL has changed, I believe). Recently, one of my systems gets kernel panics much more often than usual. Usually, the system runs peacefully even after weeks or months (they get rebooted due to some peripheral), but lately I have to reboot it in about every week. I don't know yet what the problem is. If I remember correctly, the problem occurs after I have changed _all_ the filesystems to reiserfs (well, I did add some other stuff too). I have another system that has root partition using ext2fs; it runs without problem (well, its load is a bit lighter, if that helps). Anyway, the following would be good for preparing reiserfs partitions: ReiserFS supports crude form of bad block handling. To use it you should apply one of the following patches corresponding to your kernel version: linux-2.4.2-badblocks-1.a.diff for 2.4.2 and 2.4.3. linux-2.4.4-badblocks-1.a.diff for 2.4.4 Above patches provide new ioctl() commands for ResierFS files, that allow to mark given block as used or free in block allocation bitmap without unmounting file-system. Sad news are that ReiserFS utils currently don't support this style of bad block handling in any way. So typical scenario to create and use ReiserFS file-system on device with bad blocks is as follows: 1.Find list of bad block (by /sbin/badblocks for example). Save it somewhere. 2.Create ReiserFS file-system by /sbin/mkreiserfs 3.Create dummy file on the file-system (to exercise ioctl() on). Let's suppose it's /mnt/reiserfs-mount-point/foo, name is immaterial. 4.Mark each bad block as used through simple utility. For example as follows: while read do add-bad-block /mnt/reiserfs-mount-point/foo $REPLY used done path-to-file-with-list-of-bad-blocks 5.Before running /sbin/reiserfsck on this file-system, mark all bad-blocks as free again: while read do add-bad-block /mnt/reiserfs-mount-point/foo $REPLY free done path-to-file-with-list-of-bad-blocks mkreiserfs runs pretty fast; I didn't know that it doesn't check for bad blocks, and I thought that on every write, it checks for the bad ones first. According to the above, unfortunately, it doesn't. It's also possible that my system gets kernel panics due to the bad blocks that showed up long after the filesystem got created. I have to check it out, though (and for reminding you, the tool is /sbin/badblocks). Oki
Re: ReiserFS + 2.4.4
I'm not sure about reiserfs but at least ext3 does replays logs on read only filesystem. I'm going to check if it so with reiserfs. Here http://kt.zork.net/kernel-traffic/kt20010119_103.html#1 you can find some discussion why on jornaling filesystems log can be replayed even if filesystem is mounted as read only. OD Thanks; I'll check it out. OD If it really does, then my system is okay now. OD BTW, if it's read-only and you can still write something on the OD filesystem, why is it called read-only...? (I'm a bit dazed and OD confused...) It is called read-only because user programs that work at level of files and directories can't write on mounted filesystem. Tools that mount filesystem work on lower level. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: ReiserFS + 2.4.4
Ilya Martynov wrote: It is called read-only because user programs that work at level of files and directories can't write on mounted filesystem. Tools that mount filesystem work on lower level. I guess the guys at www.reiserfs.org should create a better startup message; currently, it says (approx.): warning... replaying transaction log on read-only filesystem. It should have been: replaying transaction log. So that the faint of hearts would be sleeping well during the nights. Oki
Re: ReiserFS + 2.4.4
William Leese wrote: oh, i didn't backup /proc and /tmp because tar spewed out a few error messages. but from what i can recall /proc is created by the kernel(?) and for /tmp the directory just needs to be recreated, correct? You'd need to recreate the /proc directory; the system uses it as the mount point (of the proc filesystem). You can safely recreate the /tmp directory; its content is always deleted on reboot. BTW, I have all my partitions running on reiserfs; problem is, when the system booted up, / partition is always mounted read-only, so that the transaction log is always replayed on, well, read-only filesystem. I have done update-rc.d -f checkfs.sh remove, so that fsck wouldn't be done on the system. But that doesn't make the root partition mounted read-write on boot. The question is, how can I set the system so that the / partition mounted read-write? TIA, Oki
Re: ReiserFS + 2.4.4
OD BTW, I have all my partitions running on reiserfs; problem is, when the OD system booted up, / partition is always mounted read-only, so that the OD transaction log is always replayed on, well, read-only filesystem. I OD have done update-rc.d -f checkfs.sh remove, so that fsck wouldn't be OD done on the system. But that doesn't make the root partition mounted OD read-write on boot. The question is, how can I set the system so that OD the / partition mounted read-write? I'm sorry but what is the problem with replaying log on read only filesystem? It should be readonly only for user's programs that use mounted filesystem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: ReiserFS + 2.4.4
On Wed, 2 May 2001, Oki DZ wrote: William Leese wrote: oh, i didn't backup /proc and /tmp because tar spewed out a few error messages. but from what i can recall /proc is created by the kernel(?) and for /tmp the directory just needs to be recreated, correct? You'd need to recreate the /proc directory; the system uses it as the mount point (of the proc filesystem). You can safely recreate the /tmp directory; its content is always deleted on reboot. BTW, I have all my partitions running on reiserfs; problem is, when the system booted up, / partition is always mounted read-only, so that the transaction log is always replayed on, well, read-only filesystem. I have done update-rc.d -f checkfs.sh remove, so that fsck wouldn't be done on the system. But that doesn't make the root partition mounted read-write on boot. The question is, how can I set the system so that the / partition mounted read-write? Using LILO? image=/vmlinuz label=Linux read-only Lose the read-only directive. Andrew
Re: ReiserFS + 2.4.4
Ilya Martynov wrote: I'm sorry but what is the problem with replaying log on read only filesystem? It should be readonly only for user's programs that use mounted filesystem. Well, my understanding is that if you have a read-only filesytem, then you wouldn't be able to write anyting to it. Having a transaction log replayed on a read-only filesystem would mean that the transactions are not written. If none is written, then you can say that the journalling filesystem is not working. If it's not working, well, your system would be left in a not-quite-good state. Oki
Re: ReiserFS + 2.4.4
Andrew Pollock wrote: Using LILO? I use Grub. Thanks for the info, I'm going to lookup the man page for the identical feature. Oki
Re: ReiserFS + 2.4.4
I'm sorry but what is the problem with replaying log on read only filesystem? It should be readonly only for user's programs that use mounted filesystem. OD Well, my understanding is that if you have a read-only filesytem, then OD you wouldn't be able to write anyting to it. Having a transaction log OD replayed on a read-only filesystem would mean that the transactions are OD not written. If none is written, then you can say that the journalling OD filesystem is not working. If it's not working, well, your system would OD be left in a not-quite-good state. I'm not sure about reiserfs but at least ext3 does replays logs on read only filesystem. I'm going to check if it so with reiserfs. Here http://kt.zork.net/kernel-traffic/kt20010119_103.html#1 you can find some discussion why on jornaling filesystems log can be replayed even if filesystem is mounted as read only. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Re: ReiserFS + 2.4.4
Here is what I did step by step on 2 separate computers to change over to reiserfs. First of all you must have a partition large enough to hold everything. Lets say you have 4 partitions and part4 is big enough to hold everything. Lets say the 4 partitions are mounted as /boot, swap, /, /var. You may have more that this but you can just extrapolate from this. So here is what the partition table would look like: part1 /boot part2 swap part3 / part4 /var The first thing to do is copy the /var partition over to the / partition so that you get a spare partition. (hopefully you have enough space to do this on /). Then you will be able to make part4 spare. So here is what you would do: stop the daemons which are accessing /var - sysklogd etc. Then unmount /var. I had trouble finding all the necessary daemons to stop to do this so what I did was edit /etc/fstab and make part4 mount on /newdisk instead of /var, make a dir called /newdisk and then reboot. Now this will cause all the logging daemons etc. to complain at startup but the system will still boot and you will still be able to login OK and all the /var stuff will be mounted as /newdisk. then copy over the /newdisk stuff onto /var (Nb. you have to copy over each of the separate subdirectories in /newdisk separately otherwise you will end up with something like /var/newdisk/subdirectories when what you want is /var/subdirectories So you just do: cp -avx /newdisk/backups /var/ cp -avx /newdisk/cache /var/ cp -avx /newdisk/lib /var/ . you get the idea. You now have a spare partition (part4) which you can umount and mkreiserfs. umount /newdisk mkreiserfs /dev/ide/host0/bus0/target0/lun0/part4 (if you use devfs notation) edit /etc/fstab and change it so that part4 mounts as reiserfs, something like: /dev/ide/host0/bus0/target0/lun0/part4 /newdisk reiserfs defaults0 0 mount /newdisk (now reiserfs) Now since part4 is large enough to hold everything you can just copy everything over to it. cp -avx / /newdisk Edit /newdisk/etc/fstab and change things so that / mounts on part4 as reiserfs and part3 is left unmounted. Edit /newdisk/etc/lilo.conf change root to: /dev/ide/host0/bus0/target0/lun0/part4 Don't need to change the other stuff cause it is better to leave /boot as is (ext2) Update the mbr and map etc for lilo (for the new boot configuration) with this: /sbin/lilo -C /newdisk/etc/lilo.conf Then reboot Now running reiserfs with partitions as follows: /boot on part1 (ext2) swap on part2 / on part4 (reiserfs) Then you can mkreiserfs /dev/ide/host0/bus0/target0/lun0/part3 edit /etc/fstab and change it so that part3 mounts as reiserfs on /newdisk mount /newdisk then copy over the /var stuff onto /newdisk (Nb. you have to copy over each of the separate subdirectories in /var separately again as explained above. cp -avx /var/backups /newdisk/ cp -avx /var/cache /newdisk/ cp -avx /var/lib /newdisk/ . and so on. Then just do rm -rf /var mkdir /var edit /etc/fstab and change the part3 line so that it mounts as /var instead of /newdisk reboot. Now you should have: part1 /boot (ext2) part2 swap part3 /var (reiserfs) part4 / (reiserfs) You will probably have other partitions than this, eg /home, /usr. If your /var partition is not big enough to hold everything then perhaps one of these other ones is. Just change the above so that you use this other one instead. Hope that helps a little. Cheers. Mark.
Re: ReiserFS + 2.4.4
Ilya Martynov wrote: I'm not sure about reiserfs but at least ext3 does replays logs on read only filesystem. I'm going to check if it so with reiserfs. Here http://kt.zork.net/kernel-traffic/kt20010119_103.html#1 you can find some discussion why on jornaling filesystems log can be replayed even if filesystem is mounted as read only. Thanks; I'll check it out. If it really does, then my system is okay now. BTW, if it's read-only and you can still write something on the filesystem, why is it called read-only...? (I'm a bit dazed and confused...) Oki
Re: ReiserFS + 2.4.4
You will need the reiserFS utils, get these rom reisers site. Its not difficult more time consuming than anything. What needs to happen is this. Say your /usr is it own partition. You need a 'spare' partition that is as big as /usr. Then you unmount the 'spare' format it as reiser (mkreiserfs /dev/hda5 for instance). This will create a reiserFS on hda5. Now, mount hda5 to say /mnt/tmp or something. Copy all the files in /usr (cp -R /usr/* /mnt/tmp) this takes awhile. After that is done and you HAVE VERIFIED that all the data coppied correctly, rm -fr /usr/*. after that, umount /dev/hda5, then mount -t reiserfs /dev/hda5 /usr. wash rinse repeat for the rest of your parts. This is what i did on one of my systems and it worked great. I have yet to succesfully umount / on a running box though. Hmm maybe i should try your boot floppy aproach. William Leese [EMAIL PROTECTED] wrote: I'm considering moving my partitions to ReiserFS. I'll not be using lilo, instead I'm using boot floppies. So, I can safely move all my partitions over to ReiserFS. I'm aware that I have to compile a kernel with ReiserFS support but apart from that I have no clue how to create the ReiserFS partitions or what alterations need to be made for everything to work properly. I'm sure theres some documentation somewhere about this, but i've been unable to find any. Can someone refresh my memory or give me a description of what needs to be done? William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/
Re: ReiserFS + 2.4.4
On Tuesday 01 May 2001 19:54, Ron Bettle wrote: You will need the reiserFS utils, get these rom reisers site. is there any reason why i should not use the packaged reiserFS utils in Sid? also, is it 'safe' to use hdparm when having reiserfs partitions? I'll be doing the following: 1) backup each dir and its subdirs with tar (tar cf /usr, tar cf /lib etc.. etc..) onto an unused vfat partition 2) rebooting the comp with a bootfloppy containing a kernel with reiserfs support compiled in. 3) rm -rf /usr, /lib.. etc after mounting the vfat partition which also contains a copy of /sbin and /bin untarred. 4) with fdisk remove /dev/hda5 (current / partition) and recreate it. mkreiserfs /dev/hda5 5) mount and untar the made tarballs onto the new reiserfs partition 6) cleanup fstab current partitioning has /home and /var on different partitions, with the move to reiserfs i'll first put everything on one partition to keep things simple and shortly after mkreiserfs the /var and /home partitions, and move /var and /home to their previous partitions not exactly efficient, but simple enough to not make any large mistakes.. (i hope, but if something goes seriously wrong i still have everything in tarballs on the vfat partition) any flaws in this game plan?
Re: ReiserFS + 2.4.4
not exactly efficient, but simple enough to not make any large mistakes.. (i hope, but if something goes seriously wrong i still have everything in tarballs on the vfat partition) oh, i didn't backup /proc and /tmp because tar spewed out a few error messages. but from what i can recall /proc is created by the kernel(?) and for /tmp the directory just needs to be recreated, correct?
Re: ReiserFS + 2.4.4
http://www.reiserfs.com/install.html William Leese [EMAIL PROTECTED] wrote: I'm considering moving my partitions to ReiserFS. I'll not be using lilo, instead I'm using boot floppies. So, I can safely move all my partitions over to ReiserFS. I'm aware that I have to compile a kernel with ReiserFS support but apart from that I have no clue how to create the ReiserFS partitions or what alterations need to be made for everything to work properly. I'm sure theres some documentation somewhere about this, but i've been unable to find any. Can someone refresh my memory or give me a description of what needs to be done? William -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/
Re: ReiserFS + 2.4.4
Sounds fool proof(your plan that is). hdparms and reiser, havent done this yet myself. I would think it would work fine though. I dont think hdparms cares whats actually on the disk. heh rm -fr the directories before copyin, even with a tar backup would scare me =). Hope it works for you let us all know how it goes. William Leese [EMAIL PROTECTED] wrote: not exactly efficient, but simple enough to not make any large mistakes.. (i hope, but if something goes seriously wrong i still have everything in tarballs on the vfat partition) oh, i didn't backup /proc and /tmp because tar spewed out a few error messages. but from what i can recall /proc is created by the kernel(?) and for /tmp the directory just needs to be recreated, correct? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/
Re: ReiserFS + 2.4.4
On Tuesday 01 May 2001 21:38, Ron Bettle wrote: Sounds fool proof(your plan that is). hdparms and reiser, havent done this yet myself. I would think it would work fine though. I dont think hdparms cares whats actually on the disk. i think the same, but better safe than sorry :) heh rm -fr the directories before copyin, even with a tar backup would scare me =). Hope it works for you let us all know how it goes. well, i have a day off tomorrow and this is a home computer so if i mess up i'll have enough time to fix it. anyhow, after reinstalling windows +20 times i've become slightly numb to the fear of dataloss ;) - From: DvB [EMAIL PROTECTED] http://www.reiserfs.com/install.html cheers, however its rather basic to say the very least. off to kill my HD :)
Re: ReiserFS + 2.4.4
On Tue, May 01, 2001 at 03:38:54PM -0400, Ron Bettle wrote: Sounds fool proof(your plan that is). This depends on how much disk spaces you have. If you do not install X programs, 500MB is sufficient for Linux. I would rather make 500MB worth extra space by reorganizing current system and do not erase at all. Then play with new FS and make sure it works. Dual/triple boot system is the way to test new system. (I am not skilled enough to do chroot. :-) If you need to do major reorganization involving root, booting with single floppy Linux and mounting HD may be a way to avoid problem you listed. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED], GnuPG-key: 1024D/D5DE453D + + My debian quick-reference, http://www.aokiconsulting.com/quick/+
Re: ReiserFS + 2.4.4
On Tue, May 01, 2001 at 01:54:58PM -0400, Ron Bettle wrote: You will need the reiserFS utils, get these rom reisers site. Its not difficult more time consuming than anything. What needs to happen is this. Say your /usr is it own partition. You need a 'spare' partition that is as big as /usr. Then you unmount the 'spare' format it as reiser (mkreiserfs /dev/hda5 for instance). This will create a reiserFS on hda5. Now, mount hda5 to say /mnt/tmp or something. Copy all the files in /usr (cp -R /usr/* /mnt/tmp) this takes awhile. After that is done and you HAVE VERIFIED that all the data coppied correctly, rm -fr /usr/*. after that, umount /dev/hda5, then mount -t reiserfs /dev/hda5 /usr. cp -R is a horribly wrong thing to use for this task, it will destroy symlinks and hardlinks. turning them into duplicate files. use cpio or tar. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpkyDbkw6sz8.pgp Description: PGP signature
Re: ReiserFS + 2.4.4
Ethan == Ethan Benson [EMAIL PROTECTED] writes: Ethan cp -R is a horribly wrong thing to use for this task, it Ethan will destroy symlinks and hardlinks. turning them into Ethan duplicate files. use cpio or tar. or cp -a will preserve everything, too, I think. I often use the -x parameter, too (stay on one file system). -- Brian May [EMAIL PROTECTED]
Re: ReiserFS + 2.4.4
William Leese wrote: also, is it 'safe' to use hdparm when having reiserfs partitions? If you used it with ext2 partitions, I don't see why using it with reiserfs would be a problem. It's all disk access. I'll be doing the following: 1) backup each dir and its subdirs with tar (tar cf /usr, tar cf /lib etc.. etc..) onto an unused vfat partition Okay 2) rebooting the comp with a bootfloppy containing a kernel with reiserfs support compiled in. Yep. 3) rm -rf /usr, /lib.. etc after mounting the vfat partition which also contains a copy of /sbin and /bin untarred. Hmmm... aren't there important things in /lib, namely libc? I'm also not convinced that running /sbin and /bin binaries from a vfat partition is a good idea. I would instead make a few large files on the vfat partition, format them ext2, mount them via loopback and then copy /sbin and /bin to them. At least then you'll have proper permissions and symlinks etc will work. 4) with fdisk remove /dev/hda5 (current / partition) and recreate it. mkreiserfs /dev/hda5 It shouldn't be necessary to remove and recreate the partition with fdisk (unless you're planning to resize it, I guess). Just run mkreiserfs over it and see what happens. Matthew
Re: ReiserFS + 2.4.4
3) rm -rf /usr, /lib.. etc after mounting the vfat partition which also contains a copy of /sbin and /bin untarred. Hmmm... aren't there important things in /lib, namely libc? would that be needed for running mkreiserfs, tar and perhaps a few other gnu tools? because thats all that is needed really, just to make the reiser partition and use tar to untar the system backup. I'm also not convinced that running /sbin and /bin binaries from a vfat partition is a good idea. I would instead make a few large files on the vfat partition, format them ext2, mount them via loopback and then copy /sbin and /bin to them. At least then you'll have proper permissions and symlinks etc will work. well, to play it safe i've copied them both into /home so that i can safely restore the / partition to its original and have all the basic file utils available while i switch /home and /var to reiserfs also. once again, very unefficient, but i want to keep things very simple :) 4) with fdisk remove /dev/hda5 (current / partition) and recreate it. mkreiserfs /dev/hda5 It shouldn't be necessary to remove and recreate the partition with fdisk (unless you're planning to resize it, I guess). Just run mkreiserfs over it and see what happens cheers, William
Re: ReiserFS + 2.4.4
William Leese wrote: 3) rm -rf /usr, /lib.. etc after mounting the vfat partition which also contains a copy of /sbin and /bin untarred. Hmmm... aren't there important things in /lib, namely libc? would that be needed for running mkreiserfs, tar and perhaps a few other gnu tools? because thats all that is needed really, just to make the reiser partition and use tar to untar the system backup. On an old redhat system here (I don't have access to a Debian system ATM), tar is dynamically linked: $ which tar /bin/tar $ ldd /bin/tar /lib/libNoVersion.so.1 = /lib/libNoVersion.so.1 (0x40015000) libc.so.6 = /lib/libc.so.6 (0x4001f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Debian is probably similar, so most likely /lib and its contents will be needed.
Re: ReiserFS + 2.4.4
$ which tar /bin/tar $ ldd /bin/tar /lib/libNoVersion.so.1 = /lib/libNoVersion.so.1 (0x40015000) libc.so.6 = /lib/libc.so.6 (0x4001f000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Debian is probably similar, so most likely /lib and its contents will be needed. mm, thanks you mentioning.. it would have been a nasty surprise to find that i could not untar the backup.
Re: ReiserFS + 2.4.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hdparms and reiser, havent done this yet myself. I would think it would work fine though. I dont think hdparms cares whats actually on the disk. I've been doing hdoarm -d 1 on my disk holding a couple of heavily-used ReiserFS partitions. No troubles so far. - -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrival: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE673BiDNor2+l1i30RAu4ZAKCKShQTEMgzC1T3fUoqnnNRSyHVIgCgw2H1 7Nkr/rFqIRPgL2XMFwmW7FQ= =553m -END PGP SIGNATURE-
Re: ReiserFS + 2.4.4
On Wed, May 02, 2001 at 09:06:04AM +1000, Brian May wrote: Ethan == Ethan Benson [EMAIL PROTECTED] writes: Ethan cp -R is a horribly wrong thing to use for this task, it Ethan will destroy symlinks and hardlinks. turning them into Ethan duplicate files. use cpio or tar. or cp -a will preserve everything, too, I think. I often use the -x parameter, too (stay on one file system). There are porblems with symlinks in the target location using cp... the best way is to do something like: # tar cf - /usr | ( cd /new_partition ; tar xf - ) -B -- Brandon High [EMAIL PROTECTED] I'm not a complete idiot; some parts are missing!