• This forum is the machine-generated translation of www.cad3d.it/forum1 - the Italian design community. Several terms are not translated correctly.

pause at rescue

  • Thread starter Thread starter Cristallo
  • Start date Start date

Cristallo

Guest
on a file I'm working on, autocad is giving me a rather unusual problem, which I explain.
the funzine file quietly, audit does not find errors, it has been purged up to the bone but in the rescue phase (command saved or saved as) all free up for 30 seconds, before proceeding to writing on disk.
I see from the disk activity spies (we talk about a laptop) that as soon as you launch the "save", on the command line appears the save command echo, the disk remains unused, pass these (interminable) 15-20-30 seconds, then suddenly the rescue progress bar appears and the file is written on disk (on relative ignition of the disk activity spy) in about 1 second.

for god's love, the file is heavy, 9 mega for about 120 thousand objects (they are 60 tables), each table has its cover block that recalls an external xref, many blocks with attributes, but what I do not explain is the real pause between the save command and the actual writing on disk.
the ram is so much (12 gb), the disk is a mechanic but at 7200 turns, the processor is an i7 quadcore, the autocad is 2010 under win10.
you would have some advice, since then on the fixed (configuration very similar, except for ssd s.o. but always given on mechanic 7200) this behavior does not happen?
 
boh... I shoot a second me the difference lies in the difference between hd and ssd on how they read and write files especially if they are very fragmented total 9mbs are composed by a myriad of small files-
 
assuming that xrefs are on the same disk and not on the net test with savefidelity = 0 and already that there are tests different combinations of indexctl and xloadctl, never...
 
savefidelity... but how many you know!!
I have to try, although theoretically I have no annotative objects in the file, but I imported them from other drawings now purged, so maybe.. .

taurus, no file is unique, no fragments.
as I said the file in writing takes less than 1 sec. are the 30 between the saved command and the actual beginning of writing that are a case.
even where I have the program on ssd, the data is on mechanic and the problem does not exist. who knows if it is the location of the temporary ones that affects...
 
savefidelity... but how many you know!!
I have to try, although theoretically I have no annotative objects in the file, but I imported them from other drawings now purged, so maybe.. .

taurus, no file is unique, no fragments.
as I said the file in writing takes less than 1 sec. are the 30 between the saved command and the actual beginning of writing that are a case.
even where I have the program on ssd, the data is on mechanic and the problem does not exist. who knows if it is the location of the temporary ones that affects...
Hello crystal!!! by curiosity have you solved? ? ?
 
Not yet. I have the idea to mount on a nice ssd from 1tb, but spend 300k and then find that maybe it is a problem of ram a little brakes me
 
disk change can solve you many other problems like booting and loading applications. But it's really strange, a car so it shouldn't give some problems
 
I was also thinking that right before the rescue is created the bak file, maybe it's what creates problems
 

Forum statistics

Threads
44,997
Messages
339,767
Members
4
Latest member
ibt

Members online

No members online now.
Back
Top