note that on a large file system with a large number of files, thats
VERY expensive, as rsync has to keep a list of every inode number on the
whole file system and verify each directory entry isn't pointing to an
inode its already linked. if there's a few million files, this data
structure
On 03/19/2014 01:37 PM, John R Pierce wrote:
On 3/19/2014 6:36 AM, Radu Radutiu wrote:
I'll modify my rsync command to preserve hard links.
note that on a large file system with a large number of files, thats
VERY expensive, as rsync has to keep a list of every inode number on the
whole file
I have an ext4 filesystem for which the reported disk usage is not
correct. I have noticed the discrepancy after I rsync-ed the content to
another filesystem and noticed that the used space on the target is almost
double of the size reported on the source.
Both machines are running the same
On Wed, Mar 19, 2014 at 8:14 AM, Radu Radutiu rradu...@gmail.com wrote:
I have an ext4 filesystem for which the reported disk usage is not
correct. I have noticed the discrepancy after I rsync-ed the content to
another filesystem and noticed that the used space on the target is almost
double
No process is reading or writing to the target filesytem (it is a backup
machine) or the source machine (I am working on a LVM snapshot but the
problem exists for the source filesytem as well). The problem I describe is
on the same machine (the source).
On Wed, Mar 19, 2014 at 2:33 PM,
On Wed, 19 Mar 2014 14:14:04 +0200
Radu Radutiu rradu...@gmail.com wrote:
Do you have any idea what could cause this behaviour?
http://mradomski.wordpress.com/2007/01/08/finding-an-unlinked-open-file-and-other-lsof-uses/
--
Peace was the way.
-- Kirk, The City on the Edge of
On 03/19/2014 07:14 AM, Radu Radutiu wrote:
I have an ext4 filesystem for which the reported disk usage is not
correct.
...
Here is the du output for for one directory exhibiting the problem:
#du -h |grep \/51
201M./51/msg/8
567M./51/msg/9
237M./51/msg/6
279M./51/msg/0
http://mradomski.wordpress.com/2007/01/08/finding-an-unlinked-open-file-and-other-lsof-uses/
There are no open files. The filesystem was unmounted, verified (fsck) ,
mounted again - the behavior remains.
___
CentOS mailing list
CentOS@centos.org
The space used by hard-linked files will be included only in the first
directory where they are encountered. In your first case, linked files
seen prior to the /51 directory would not have had their space included
again under that directory. In the second case, _only_ the /51 directory
is
On 3/19/2014 6:36 AM, Radu Radutiu wrote:
I'll modify my rsync command to preserve hard links.
note that on a large file system with a large number of files, thats
VERY expensive, as rsync has to keep a list of every inode number on the
whole file system and verify each directory entry isn't
10 matches
Mail list logo
