how do I reverse get rid of things due to dd command
 

Hi

I have done the following

dd if=/dev/zero of=/dev/mapper/asm-data1 bs=4k count=100
100+0 records in
100+0 records out

later I realize that there's something wrong.

I realize that asm-data is not an alias i created in multipath.config, i.e. my multipath.config does not consist of these alias.

What should I do to get of the unwanted entries /dev/mapper/asm-data*, i.e. /dev/mapper/asm-data-disk1 to /dev/mapper/asm-data-disk4

I'm using Suse 11.

thanks a lot!

Hmm, the usual way to get rid of a file is the rm command. It works well for both regular files and symbolic links. Somehow I believe this is not what you want, but your question is a bit unclear.

the original command is meant to test whether we can access each device according to a document. I believe we cannot use the cp command is because we are dealing with disks/blocks. since the create command is dd i wonder if there'a another command to remove the things which dd command created. thanks

The asm-data-disk[1-4] files are ordinary files that do not belong in the /dev/mapper/ directory, but there is nothing that prevents root from creating ordinary files there. You can remove them with the rm command just like any other ordinary file.

The asm-data1 and asm-data1_part1 symbolic links are the type of things that belong there and were apparently created by the device mapper. You should leave those alone. You can use the "dmsetup info" command to get more information about those entries.

'dd' stands for data destroyer ... so no there is no way to directly undo it. Now, you can recreate a partition or partition table if that's what was overwritten, or copy files back from your backups if you have them.

This seems weird what you're doing.

rm will remove a file or symbolic link. That file is owned by root and has 777 permissions on it, so it should be removable in a normal fashion, actually by any user on the system, providing that user can view the /dev/mapper directory.

Now, /dev/zero is "nothing" you used that as your input file. You specified your output file as a new file. How that file became a symbolic link is nothing I understand or can see why that occurred, my guess is some other actions were performed to make that happen. Not sure if the file was pre-existing and already a symbolic link whether or not injecting /dev/zero into it would've altered it at all. I actually just did a test on a text file, I made a copy, then used your dd command and the result was it did nothing to my text file copy, in fact the copy still matches the original. So, my impression is that /dev/mapper/asm-data1 existed before and you should leave it alone, because it was NOT created by your dd command, it was there all along.

Back to your "access each device according to a document"; what's that mean? Is this a validation procedure where you're trying to satisfy a test criteria? If these are disks, then accessing them means being able to view files, view directories, or view the actual device file(s). Therefore you should be doing nothing related to dd. You should maybe grep for expected content, try to open and view the file, or copy the file to somewhere to verify you can access it and then remove the copy once you've validated you were able to copy one for one.

The /dev/ location is one of those special filesystems. Before udev you would use mknod or MAKEDEV to create entries in that filesystem. With udev the /dev/ path should be mostly empty before you boot. With various hints in /proc/devices and /proc/misc of what should exist if you have to add udev rules or go old school.

Back in the day I would use the wrong redirect or pipe for /dev/null and that would overwrite the device node and create a file that used disk space. Which I had to rm and use mknod or MAKEDEV to recreate /dev/null.

Remember the days when "jerks" would try to tell people to sign in as root, cd to / and then type "rm -rf *" to "clean-up" their drive space? (Don't anyone EVER do that! OK?)

Shadow's point, and mine are that you ought to be careful here. All directories aren't just for "play", you know. Or experiment on a throwaway system, not your server or work station which you use everyday for work.