with reference now to the figures , fig2 depicts a pictorial representation of a network of data processing systems in which the present invention may be implemented . network data processing system 200 is a network of computers in which the present invention may be implemented . network data processing system 200 contains a network 202 , which is the medium used to provide communication links between various devices and computers connected together within network data processing system 200 . network 202 may include connections , such as wire , wireless communication links , or fiber optic cables . in the depicted example , server 204 is connected to network 202 along with storage unit 206 . in addition , clients 208 , 210 , and 212 are connected to network 202 . these clients 208 , 210 , and 212 may be , for example , personal computers or network computers . in the depicted example , server 204 provides data , such as boot files , operating system images , and applications to clients 208 - 212 . clients 208 , 210 , and 212 are clients to server 204 . network data processing system 200 may include additional servers , clients , and other devices not shown . in the depicted example , network data processing system 200 is the internet with network 202 representing a worldwide collection of networks and gateways that use the transmission control protocol / internet protocol ( tcp / ip ) suite of protocols to communicate with one another . at the heart of the internet is a backbone of high - speed data communication lines between major nodes or host computers , consisting of thousands of commercial , government , educational and other computer systems that route data and messages . of course , network data processing system 200 also may be implemented as a number of different types of networks , such as for example , an intranet , a local area network ( lan ), or a wide area network ( wan ). fig2 is intended as an example , and not as an architectural limitation for the present invention . referring to fig3 , a block diagram of a data processing system that may be implemented as a server , such as server 204 in fig2 , is depicted in accordance with a preferred embodiment of the present invention . data processing system 300 may be a symmetric multiprocessor ( smp ) system including a plurality of processors 302 and 304 connected to system bus 306 . alternatively , a single processor system may be employed . also connected to system bus 306 is memory controller / cache 308 , which provides an interface to local memory 309 . i / o bus bridge 310 is connected to system bus 306 and provides an interface to i / o bus 312 . memory controller / cache 308 and i / o bus bridge 310 may be integrated as depicted . peripheral component interconnect ( pci ) bus bridge 314 connected to i / o bus 312 provides an interface to pci local bus 316 . a number of modems may be connected to pci local bus 316 . typical pci bus implementations will support four pci expansion slots or add - in connectors . communications links to clients 208 - 212 in fig2 may be provided through modem 318 and network adapter 320 connected to pci local bus 316 through add - in boards . additional pci bus bridges 322 and 324 provide interfaces for additional pci local buses 326 and 328 , from which additional modems or network adapters may be supported . in this manner , data processing system 300 allows connections to multiple network computers . a memory - mapped graphics adapter 330 and hard disk 332 may also be connected to i / o bus 312 as depicted , either directly or indirectly . those of ordinary skill in the art will appreciate that the hardware depicted in fig3 may vary . for example , other peripheral devices , such as optical disk drives and the like , also may be used in addition to or in place of the hardware depicted . the depicted example is not meant to imply architectural limitations with respect to the present invention . the data processing system depicted in fig3 may be , for example , an ibm eserver pseries system , a product of international business machines corporation in armonk , n . y ., running the advanced interactive executive ( aix ) os , linux os , or any other appropriate os . essentially , in accordance with an exemplary embodiment of the present invention , as each resource ( e . g ., data file ) is acquired by a filesystem operation and the resource &# 39 ; s data modified or changed , the filesystem operation stores “ undo ” information for that resource that can be used to reverse the changes . also , the filesystem operation determines if other “ undo ” information is present for that resource , before the operation adds its own “ undo ” information . the filesystem operation determines , if any , which threads created the other “ undo ” information . as such , the filesystem operation considers the other “ undo ” information as “ uncommitted updates ” and that the other threads &# 39 ; operations are not yet complete . in a “ normal ” or “ non - error ” path ( e . g ., no filesystem operation error has occurred ), the filesystem operation modifies or changes all of the pertinent resources ( data files ), completes the entire operation , and then remains in a wait state . at this point , the filesystem operation waits for all other threads that had uncommitted updates on the resources involved . the filesystem operation allows all of the other threads to complete their operations successfully , before the filesystem operation can commit to the use of its undo information ( thereby removing the changes that were made by the filesystem operation ). after the other threads have committed and used their undo information successfully , the filesystem operation , for the thread being run , can remove all of the undo blocked information for its resources , and then “ wake up ” any of the other threads that are waiting for the filesystem operation to be completed . notably , in accordance with the present invention , if a deadlock situation occurs whereby two resources are modified in different orders , but both modifications are successful , both sets of undo blocks can be removed . if an error occurs during the filesystem operation , the filesystem can review each resource that it has modified and determine if other threads have also modified resources in addition to the filesystem &# 39 ; s initial modifications . if such other modifications are found , the threads that performed these modifications are considered to be in a wait state and waiting for the particular thread &# 39 ; s operation that failed ( due to the error involved ). the failed thread then notifies the later ( in time ) threads that an operation has failed and all modifications that the other threads made are to be “ undone ”. each thread is then run and all metadata changes are “ undone ”. the failed thread can wait for a repair process or an input / output command to complete its operation . thus , the failed thread and the other threads have returned the filesystem to a previous , consistent state . specifically , fig4 a - 4c depict a flow showing the handling of a filesystem operation failure according to an exemplary embodiment of the present invention . in this exemplary embodiment , the filesystem can be located , for example , on hard disk 332 of fig3 , and the filesystem operation shown can be , for example , a file removal or unlinking operation being executed by a linux or aix os . referring to fig4 a , in this exemplary method , the flowchart is entered during a filesystem operation when the filesystem is updating an inode page ( file data ) for a file ( step 402 ). for example , at step 402 , the filesystem changes the object - specific data in the inode page for a particular thread associated with the file of interest ( e . g ., time of operation , regular file , etc .) and records the changes that were made . the filesystem can store the recorded changes , for example , on hard disk 332 of fig3 . fig4 b illustrates an exemplary change made to a thread ( e . g ., thread 1 ) in the inode page for the file of interest , after the completion of step 402 . next , the filesystem then updates a directory associated with the file of interest ( step 404 ). an exemplary directory can be for an inverted tree structure . for example , at step 404 , the filesystem changes certain data in the directory page for the thread described above with respect to step 402 , and records the changes made . for a file removal operation , the directory change may be the deletion of the previous entry . the filesystem can store the recorded changes , for example , on hard disk 332 of fig3 . fig4 c illustrates an exemplary change made to a thread ( e . g ., thread 1 ) in the directory page associated with the file of interest , after the completion of step 404 . after the update and record change occurs , it is assumed that an error has occurred in the filesystem operation shown ( step 406 ). in accordance with the present invention , the filesystem retrieves ( e . g ., from hard disk 332 of fig3 ) the stored changes made to the data in the updated directory , and reverses those changes using , for example , an “ undo ” command ( step 408 ). for example , the previously deleted entry is restored to the directory page . similarly , the filesystem retrieves the stored changes made to the file data in the updated inode , and reverses those changes also using , for example , an “ undo ” command ( step 410 ). notably , at this point , the filesystem has been returned to a consistent state . as a result , the data in the filesystem is again available for use even if the operational problem has not been corrected . the filesystem can send an error message to the user , in order to alert the user to the operational problem that has occurred ( step 412 ). at this point , the filesystem is “ clean ”. fig5 a - 5c depict an alternative flow showing the handling of a filesystem operation failure according to an exemplary embodiment of the present invention . in this exemplary embodiment , the filesystem operation shown is a multi - thread operation , instead of the exemplary single thread operation described above with respect to fig4 a - 4c . also , similar to the filesystem described above with respect to fig4 a - 4c , the filesystem associated with fig5 a - 5c can be located , for example , on hard disk 332 of fig3 , and the filesystem operation shown can be , for example , a file removal or unlinking operation being executed by a linux or aix os . essentially , the exemplary embodiment of fig5 a - 5c provides a method for ensuring that later changes to a filesystem can be “ undone ” so as to return a filesystem to a consistent state , by ensuring that no operation is fully successful until the preceding operations that changed the same metadata are also successful . if a filesystem operation error has occurred , the filesystem operation can review every resource that the filesystem has changed to determine if other threads have modified data in addition to the initial changes . a failing thread notifies other threads that a filesystem operation has failed and all previous changes need to be “ undone ”. each of the other threads then continues its operation and “ undoes ” all pertinent metadata changes . thus , the filesystem is “ clean ” and returned to a previous , consistent state . specifically , referring to fig5 a , in this exemplary method , the flowchart is entered during a filesystem operation when the filesystem is updating an inode page with data for a file associated with a particular thread ( step 502 ). the relative timing of the exemplary steps in the filesystem operation of fig5 a is denoted by t = 0 , 1 , 2 , 3 , . . . 8 as shown in an example timing unit for t . for example , at t = 0 , the filesystem changes the object - specific data in the inode page for thread 2 for the file of interest ( e . g ., time stamp for the operation , regular file , etc .) and records the changes made ( step 502 ). the filesystem can store the recorded changes , for example , on hard disk 332 of fig3 . at t = 1 , the filesystem changes the object - specific data in the inode page with data for thread 1 associated with the file of interest ( e . g ., time stamp for the operation , regular file , etc . ), and records or stores the changes made ( step 504 ). since there is already a changed record from thread 2 , the changes to the inode page for thread 1 are chained to the end of those from thread 2 . fig5 b illustrates exemplary changes made to the data associated with the threads ( e . g ., threads 1 and 2 ) in the inode page of the file of interest , after the completion of step 504 ( t = 1 ). at t = 2 , the filesystem changes certain data in the directory page for thread 1 for the file of interest , and records or stores the changes made ( step 506 ). at t = 3 , the filesystem also changes the data in the directory page for thread 2 for the file of interest , and records or stores the changes made ( step 508 ). since there is already a changed record from thread 1 , the changes to the directory page for thread 2 are chained to the end of those from thread 1 . for example , fig5 c illustrates the exemplary changes 1 and 2 made to the data associated with threads 1 and 2 in the directory page for the file of interest , after the completion of step 508 ( t = 3 ). at t = 4 , because of the interdependency of the files associated with the operations being performed for both threads 1 and 2 , the filesystem delays the timing of the operations for thread 2 until the operations for thread 1 are appropriately synchronized with those of thread 2 ( step 510 ). specifically , thread 2 reviews its changes that were made , and also determines that thread 1 had made at least one change prior to those of thread 2 . consequently , thread 2 is required to wait for thread 1 to complete its operations before thread 2 can continue its operations , because thread 1 may want to request thread 2 to abort its operations . after the update and record changes occur , at t = 5 , it is assumed that an error has occurred with respect to thread 1 in the filesystem operations shown ( step 512 ). in accordance with the present invention , at t = 6 , the filesystem retrieves ( e . g ., from hard disk 332 of fig3 ) the stored changes made to the data in the updated inode page for thread 1 , and attempts to reverse those changes using , for example , an “ undo ” command ( step 514 ). notably , thread 1 attempts to rollback these changes as much as possible . however , the only “ outer level ” change thread 1 can make is to rollback the changes that were made to the inode page . thread 1 notifies thread 2 to abort its filesystem operations ( step 514 ). similarly , at t = 7 , the filesystem retrieves the stored changes made to the data in the updated inode page and directory page for thread 2 , and reverses those changes using , for example , an “ undo ” command ( step 516 ). specifically , thread 2 aborts both changes , because now both of the thread 2 changes are “ outer level ” changes . also , at t = 8 , the filesystem retrieves the stored changes made to the data in the updated directory page for thread 1 , and reverses those changes again using , for example , an “ undo ” command ( step 518 ). notably , at this point , the filesystem depicted in fig5 a - 5c has been returned to a consistent state . as a result , the data in the filesystem is again available for use even if the operational problem ( step 512 ) has not been corrected . finally , both threads 1 and 2 send an error message to the user , in order to alert the user to the operational problem that has occurred ( step 520 ). at this point , the filesystem is “ clean ”. it is important to note that although an “ undo ” command is described above as being used to rollback or reverse changes that have been made during the filesystem operations , the present invention is not intended to be so limited . other appropriate commands , instructions or processes may be used to rollback or reverse such changes , in order to return a filesystem to a consistent state , and still be covered by the present invention . it is also important to note that while the present invention has been described in the context of a fully functioning data processing system , those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution . examples of computer readable media include recordable - type media , such as a floppy disk , a hard disk drive , a ram , cd - roms , dvd - roms , and transmission - type media , such as digital and analog communications links , wired or wireless communications links using transmission forms , such as , for example , radio frequency and light wave transmissions . the computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system . the description of the present invention has been presented for purposes of illustration and description , and is not intended to be exhaustive or limited to the invention in the form disclosed . many modifications and variations will be apparent to those of ordinary skill in the art . the embodiment was chosen and described in order to best explain the principles of the invention , the practical application , and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated .