Is it risky to rename folder with 180GB with the
We have a folder
/data that contain 180GB.
We want to rename the
/data folder to
/BD_FILES with the
Is it safe to do that?
Changing the name on a folder is safe, if it stays within the same file system.
If it is a mount point (
/data kinda looks like it could be a mount point to me, check this with
mount), then you need to do something other than just a simple
mv /data /BD_FILES would move the data to the root partition (which may not be what you want to happen).
You should unmount the filesystem, rename the now empty directory, update
/etc/fstab with the new location for this filesystem, and then remount the filesystem at the renamed location.
In other words,
mv /data /BD_FILES(assuming
/BD_FILESdoesn't already exist, in that case, move it out of the way first)
/etc/fstab, changing the mount point from
This does not involve copying any files around, it just changes the name of the directory that acts as the mount point for the filesystem.
If the renaming of the directory involves moving it to a new file system (which would be the case if
/data is on one disk while
/BD_FILES is on another disk, a common thing to do if you're moving things to a bigger partition, for example), I'd recommend copying the data while leaving the original intact until you can check that the copy is ok. You may do this with
rsync -a /data/ /BD_FILES/
for example, but see the
rsync manual for what this does and does not do (it does not preserve hard links, for example).
Once the folder is renamed, you also need to make sure that existing procedures (programs and users using the folder, backups etc.) are aware of the name change.
You aren't renaming every file in the directory, you're renaming one file in /. That's because:
Thus, renaming a directory, no matter how many files or how much data is in it, is trivial.
If you just rename (source and target in same file system), it is simply a rename of a directory entry. It either succeeds and the directory has new name, or fails in which case nothing changes *.
If the source and target are on different file systems the data needs to be copied by
mv. Differences in file system features, such as maximum file size, limitations in file names, etc., can cause problems. To avoid issues, first copy files (
rsync, …) and after copy completes successfully, remove the files in the original location.
* However there are some corner cases, for example mentioned in the BUGS section in man 2 rename
As others have said, renaming a folder poses no inherent risk to the contents. But there is a different kind of risk you may want to consider.
Existing procedures, scripts, user-defined shortcuts, and configurations which reference the original location could be broken by this change, and if the paths are stored in a database, for example, updating them could be a big job.
One thing you can do is make a symbolic link for the new directory name, but leave the old name in place for a while. That will give you time to evaluate the impact of this change. You could temporarily remove the old name, see if there are any problems, and if there are, just recreate the old name so people can continue working while you figure out what needs to be updated.
A command something like this should do it :
ln -s /data /BD_FILES
Rename is atomic. The only reasonable risk is that
mv decides to copy everything for some reason and that crashes half way through. If you have GNU
mv -T will remove this risk.
mv -T tells
mv that it's moving to a non-folder; which will cause it to refuse to do
mkdir() which in turn will cause it to fail if moving a folder and it decided to copy for some reason.
I was involved in shaking bugs out of
mv -T while working on my master's thesis years ago. It used to do the wrong thing on too many edge cases.
On the other hand, you have 180GB of user data on the root partition. You probably do want to move this off the root partition.