copy a filesystem best solution (local host or remote host)

[support_billa]

>> You may have to use tusc to trace the bad system call.

i use following "tusc" command :

/usr/local/bin/tusc  -o /tmp/tusc.log -fakE find . -type f -exec cksum {} + | sort -k3,3 > /tmp/cksum

in the attachment is a little report , the whole file /tmp/tusc.log contain 3637931 lines and has the size 359 MB.

it seems that "cksum" have problems with so many files ?

regards,

[James R. Ferguson]

Hi (again):

THe 'tusc()' output confirms that the files in question do not exist.  Notice the ENOENT (Error NO Entity) errors for the open()'s.

I think mixing into this thread questions about VxFS file layout versions has caused you to miss reading and responding to this query I posted to you earlier this week in this thread; viz.:

None of the directories you have shown look particularly large.  One thought that occurs to me is to ask if files can be removed frequently.  That is, the directory's by nature are volatile.

If between the time 'find()' finds a file and the time that *name* is passed to 'cksum()' if the file disappears, an error would be produced.  This may be what is happening.

Regards!

...JRF...

[support_billa]

@ I think mixing into this thread questions about VxFS file layout versions has caused you to miss reading and responding
@ to this query I posted to you earlier this week in this thread; viz.:

sorry, sorry. i am a little bit busy.
we made a storage migration with many filesystem(s) (not large) in june. i developed a script due to the informations of this
thread. i thought my script contains a lot of error queries ... i was a unknowing  guy ...
 
@ None of the directories you have shown look particularly large. 
yes, there are a lot of small text-plain files produced by databases !
@ One thought that occurs to me is to ask if files can be removed frequently. 
we remove it regularly !
@ That is, the directory's by nature are volatile.
a lot of things can be better at our servers ... i agree to

@If between the time 'find()' finds a file and the time that *name* is passed to 'cksum()' if the file disappears, an error would be @produced.  This may be what is happening.

i understand your information, but we can do nothing ? we detect the problem but can't fix it , right ?

regards

[support_billa]

i have to thank you at this time to all response i get in this thread and sorry when i don't answer in time.

i am working now in a project which copy filesystems and oracle databases to a new storage systems.

i developed a script due to the informations of this thread and i have to adapt my copy script frequently ...

- reasons :

- when i want to "umount" the filesystems , i have to check next to "fuser" command and if it is a "nfs share",
  but i forget to check , if the "nfs share" containts sub directories of the filesystem (like /fs/subdir )
- i "umount" the filesystem and then i copy with "dd" and a user change to the directory in the meantime ..
  then it isn't possible to "mount" the filesystem
- Check filesystem-Versions after "dd" . We mounted the new filesystem parallel and started a "newfs" and
  thought after "dd" it has the new filesystem version of the system ...wrong accepting
- Check if filesystem isn't a large filesystem ..
- I asked here many questions about statistics of filesystems and adapt my copy script with your input's and
  then , when we want to copy it in the production environment the errors occur !!

in the attachment is the workflow of copy with "dd" a filesystem from "/old_fs" to "/new_fs"

explanation to the attachment :

umount_local_fs: means that "umount_local_fs" is a procdure which do tasks and create outputs.

i think the attachment is self-explanatory !

maybe you have any input's ?

[James R. Ferguson]

---

@support_billa wrote:

@ If between the time 'find()' finds a file and the time that *name* is passed to 'cksum()' if the file disappears, an error would be @produced.  This may be what is happening.

i understand your information, but we can do nothing ? we detect the problem but can't fix it , right ?

---

Well, you can hide errors reported for non-existent files and permission errors :

cd /srcpath && find . -type f -exec cksum {} + 2>/dev/null | sort -k3,3 > /tmp/srcpath

Regards!

...JRF...

[Dennis Handly]

>If between the time 'find()' finds a file and the time that *name* is passed to 'cksum()' if the file disappears, an error would be produced.

Right.  Especially with find -exec + and the fact that cksum(1) may take a long time to read large files.

[support_billa]

hello,

i have extended the command's of James to

# cd /srcpath && find . -type f -exec cksum {} + 2>/dev/null | sort -k3,3 > /tmp/srcpath

# cd /dstpath && find . -type f -exec cksum {} + 2>/dev/null | sort -k3,3 > /tmp/dstpath

# diff /tmp/srcpath /tmp/dstpath

 last week i copied a filesystem with about 350.000 files and then the report of
"diff /tmp/srcpath /tmp/dstpath" shows that /tmp/dstpath misses 3 files , cksums were equal.

@@Right.  Especially with find -exec + and the fact that cksum(1) may take a long time to read large files.

i agree , but i also think , with the "amount" of files there is also a problem , because in those reported filesystems
are many files with the size of about 1 or 2 kb.

@ James
it was a great idea of you to use "find .... cksum " but "cksum" doesn't work right in certain circumstances.
so i will use it for filesystem with about 10.000 files , right ?

regards

[Dennis Handly]

>with the "amount" of files there is also a problem because in those reported filesystems
are many files with the size of about 1 or 2 kb.

Only if some process is removing those files.

> "find .... cksum " but "cksum" doesn't work right in certain circumstances.

cksum(1) is working fine, someone is removing those files.

Given all of those errors in the tusc output, did those files magically reappear?  If so, then you can blame cksum.

[support_billa]

@@ Only if some process is removing those files.
@@ "find .... cksum " but "cksum" doesn't work right in certain circumstances.

@ cksum(1) is working fine, someone is removing those files.

i described in a few entries above my tasks in the attachment:

- after copy files with "dd" , i mount srcpath fs with option "ro"   like
  /usr/sbin/mount -F vxfs -o "ro"  "/dev/vgold/rlvol"  "/old_fs"
  the fs isn't in use, because our applications are stopped !

  the dstpath fs isn't also in use because we mounted it with prefix "/new"
  example:  srcpath - fs : /fs_copy
            dstpath - fs : /new/fs_copy
 
so i can guarantee , that the filesystems aren't in use !!!  right ?

[support_billa]

hello again,

i have a new question to

fsadm

before i want to upgrade to a new filesystem version layout , i should use fsadm with following options

 /usr/sbin/fsadm -F vxfs  -e -d <filesystem>

is there a  recommendation to do this ?

regards

[James R. Ferguson]

---

@support_billa wrote:

i have a new question to

fsadm

before i want to upgrade to a new filesystem version layout , i should use fsadm with following options

 /usr/sbin/fsadm -F vxfs  -e -d <filesystem>

is there a  recommendation to do this ?

---

A version layout upgrade requires a small amount of free space in the filesystem.  Unless a bdf' shows your filesystem is very near capacity, the defragmentation is unnecessary.  Have a look at the 'vxupgrade(1M)' manpages for a calculation of free space that is required.

The layout version upgrade takes only a few seconds.

Regards!

...JRF...

[James R. Ferguson]

---

@support_billa wrote:

@ James
it was a great idea of you to use "find .... cksum " but "cksum" doesn't work right in certain circumstances.
so i will use it for filesystem with about 10.000 files , right ?

---

What doesn't "work right"?  and what are the "certain circumstances".  What you are saying is that your expectations differ from reality.  Please be specific!  If you can construct an actual test case that others can replicate that is the most useful description.  That might be as simple as creating some directory (with n-subdirectories) and populating the structure with n-files with any content whatsoever.  A simple script to create the files is all that would be necessary.

Regards!

...JRF...

[Dennis Handly]

>I described in a few entries above my tasks in the attachment:

The one with "tasks_copy_with_dd.txt"?  Not as clear as this time.  ;-)

>so I can guarantee, that the filesystems aren't in use!  Right?

It seems like it.

Then you need to follow what I suggested above.  Pick one of the files that tusc said wasn't there and see if it still isn't there:

"./LN/spo-zlneu/prt/lsnr/000684320110065_523251_tbu.lst"

You may want to go up and down your tree to see if it is isolated to a specific directory or total number of files passed to cksum(1).

>What doesn't "work right"?  and what are the "certain circumstances"?

Those tusc failures I assume.

[support_billa]

@ James

A version layout upgrade requires a small amount of free space in the filesystem.  Unless a bdf' shows your filesystem is very near capacity, the defragmentation is unnecessary.  

thank you for the informations

[support_billa]

@ Dennis Handly

@ The one with "tasks_copy_with_dd.txt"?  Not as clear as this time.  ;-)

yes , you are right.

@Then you need to follow what I suggested above.  Pick one of the files that tusc said wasn't there and see if it @still isn't there:

@ "./LN/spo-zlneu/prt/lsnr/000684320110065_523251_tbu.lst"

the file has existed since aug 17 !

@You may want to go up and down your tree to see if it is isolated to a specific directory or total number of files @passed to cksum(1).

i am now restoring with DP the filesystem to test server and will test it as soon as possible.
 

>What doesn't "work right"?  and what are the "certain circumstances"?

i will trace it again with "tusc"

[support_billa]

@ JRF

@ What doesn't "work right"?  and what are the "certain circumstances".  What you are saying is that your
@ expectations differ from reality.  Please be specific!  If you can construct an actual test case that others can
@ replicate that is the most useful description.  That might be as simple as creating some directory
@(with n-subdirectories) and populating the structure with n-files with any content whatsoever. 
@ A simple script to create the files is all that would be necessary.

i wrote it in my last post, now i am restoring the files to a test server and you will get the results
today or tomorrow.

Regards!

 

[Viktor Balogh]

###

Ooops, I should used to this new forum engine, didn't notice that there are more pages to this topic. Anyway, I won't delete my response, here you are:

###

Hi,

I think this method wasn't mentioned:

If you want to move the data from old luns to new, you can do it by:

1. pvcreate the new luns

2. add the new luns to the vg

3. lvextend -m 1 # by this you create a mirror on the LVM level, the "copy" will be invisible to the users

4. lvreduce # specify the old luns as you want to remove those

and voila', your data is safe in the newly added storage. Note that the above works only if you have a MirrorDisk/UX license.

[support_billa]

hello,

thanks to all, i will answer my open tasks after my vacation

regards

[support_billa]

Hello Viktor ,

About :If you want to move the data from old luns to new, you can do it by:

1. pvcreate the new luns
2. add the new luns to the vg
3. lvextend -m 1 # by this you create a mirror on the LVM level, the "copy" will be invisible to the users
4. lvreduce # specify the old luns as you want to remove those
________________________________________________________________________________

we did this steps at many storage migrations ( we mirror Storage EVA mit LVM ).
but at this migration we upgrade the LVM version from 1 to 2.
how can you do this with your steps ?

I explain our storage move :

1. Existing VG for example vgtest                    with LVM 1.0 on the XP12000
2. Mr. Winkler create a new VG vgtest_neu    with LVM 2.0 on the  P9500
3. Copy Procedure :               1. create LVOL's and Filesystems at VG vgtest_neu
                                               2. mount all filesystems of VG vgtest_neu like /new/filesystem …
                                               3. copy with command "dd" , "umount" filesystem before copying
                                               4. after copy tasks we umount all filesystems of XP12000 and P9500
                                               5. vgexport of vgtest_neu and vgtest and replace with vgimport  vgtest_neu to vgtest    
4. After Copy Procedure : VG vgtest with LVM 2.0   is on the P9500

[support_billa]

Hello Dennis , hello James,

about the issue "find .... cksum " and  "cksum" :

our colleagues made a software call and we got the informations :
cksum can't process files when the string or shackle of files from find command is too long
hmm , i hope i explain it right ?

regards

[support_billa]

hello,

i have a new problem :

i changed my  "dd" copy job :

old:

1. dd

2. mount

3. fsadm -F vxfs  -e -d <filesystem>

4.if necessary : /usr/sbin/fsadm -F vxfs -o largefiles <filesystem>

5. information, when it necessary to do : /usr/sbin/fsadm -F vxfs -b newsize <filesystem>

new

1. dd

2. mount

3. if necessary : /usr/sbin/fsadm -F vxfs -b newsize <filesystem>

4. fsadm -F vxfs  -e -d <filesystem>

5. if necessary : /usr/sbin/fsadm -F vxfs -o largefiles <filesystem>

6. last step : when i try to umount , sometimes filesystem is busy.

i search with :

/opt/iexpress/lsof/bin/lsof -s +D <filesystem>
fuser <filesystem>

the filesystem have about 106947 files.

no process  i found and it is a test system , so i gurantee , that nobody use this fs.

i rebooted the servers and it work perfect for maybe for 5 tests it is ok, then i got "busy" ...

before i umount , i test command "sync" , it helps sometimes , then i got "busy" ...

when i use 3 times "sync" , then it is ok

is command "sync" a good solution or i say "dangerous" ? i didn't found a command, which "sync" only a

filesystem or inital a "write" or "flush" of all processes

regards

[James R. Ferguson]

---

@support_billa wrote:

Hello Dennis , hello James,

about the issue "find .... cksum " and  "cksum" :

our colleagues made a software call and we got the informations :
cksum can't process files when the string or shackle of files from find command is too long
hmm , i hope i explain it right ?

regards

---

OK, if that's the case, you can use 'xargs' to collect n-number of arguments and execute 'cksum' for each bundle until done:

# find . -type f -print | xargs -n10 cksum

In this case, if there were 31 files found, four (4) 'cksum' processes would be run --- the first three (3) handling 10-arguments and the last, forth process doing the remaining argument of one file.

This would be more efficient then using :

# find . -type f -exec cksum {} \

...which spawns one 'cksum' process for every file found.

Using:

# find . -type f -exec cksum {} +

...mimics using 'xargs' but (based on your information and your data) gives 'cksum' too many arguments to handle at once.

Regards!

...JRF...

[Dennis Handly]

>cksum can't process files when the string or shackle of files from find command is too long
hmm, I hope I explain it right?

That sounds like your problem but I'm not sure how that can happen?

[support_billa]

hello Dennis,

>cksum can't process files when the string or shackle of files from find command is too long
> hmm, I hope I explain it right?
@ That sounds like your problem but I'm not sure how that can happen?

here there statement, i hope i explain it

The command "find" reports a     appropriate number of files to command "cksum"
"cksum" has limits, which occur at a number of files,
therefore it is not a bug , but rather a result when limits where exceeded.

regards

[Dennis Handly]

>there statement, I hope I explain it
>The command "find" reports a appropriate number of files to command "cksum" . "cksum" has limits, which occur at a number of files, therefore it is not a bug, but rather a result when limits were exceeded.

Who made that statement and where is it documented?

I see nothing in cksum(1), nor in the source that indicates any limits.

Other than the command line limit that find(1) uses.

On 11.23, I have no problems passing in 33,800+ files to cksum.