[Bug 1425] New: Support file rename (move)
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 Summary: Support file rename (move) Product: Swift Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Design Decision AssignedTo: [email protected] ReportedBy: [email protected] I have an app that names checkpoint files implicitly. If I invoke it with the name "job0" it produces a checkpoint file named something like "job0-0.checkpoint". Then, if I want to resume from that checkpoint in "job1", I need to rename "job0-0.check" to "job1-0.check". Swift is happy to copy it, but it doesn't seem like there is a way to rename/move it. This is important because the checkpoint files are very large, both slowing a serial copy and requiring more disk space. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 ketan <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Version|unspecified |0.96 AssignedTo|[email protected] |[email protected] --- Comment #1 from ketan <[email protected]> 2015-06-15 16:25:49 --- Reassigned to Mihael. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 Mihael Hategan <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Mihael Hategan <[email protected]> 2015-06-19 20:24:57 --- What version of Swift is this? I committed some code to trunk to create symbolic links (on OSes that support it) when an assignment of file values happens. The only restriction is that the source must not be temporary (which it is not in this case). The code tries to resolve the source if it is a link itself. In that case, it will link to the link target even if the source itself is a temporary file. This requires at least java 1.7. Versions prior to that do not support linking. If you are using java 1.6, copying will continue to be done. This could be "fixed" by doing some command line implementation of the linking API, but I'm probably not going there. Full moving/renaming capability might be possible, but it requires reference counting for reads (to assert that nothing is trying to read from a file that is being deleted) which is currently not implemented. A naive rename (remapping it was called) was actually implemented in earlier versions. It was terribly broken, since it did not guarantee that code that was using filename(x) was not running (or scheduled to run) when the mapping of x was being modified. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 Max Hutchinson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #3 from Max Hutchinson <[email protected]> 2015-06-19 20:37:15 --- Swift trunk git-rev: 1d512cbda070d363e8ec3cf16e77dfcddc6e66cb heads/master 6377 $ java -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxp6460sr15fp1-20140110_01(SR15 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux ppc64-64 jvmxp6460sr15-20131231_180656 (JIT enabled, AOT enabled) J9VM - 20131231_180656 JIT - r9_20130920_46510ifx3 GC - GA24_Java6_SR15_20131231_1152_B180656) JCL - 20140107_01 I don't have control over those installs (mira, cetus, tukey, cooley). Under what circumstances does your code create symbolic links? I don't see anything in the docs. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 --- Comment #4 from Mihael Hategan <[email protected]> 2015-06-19 21:20:34 --- No. It won't work on 1.6. See previous reply. Can you work around the issue with an application wrapper? -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 --- Comment #5 from Max Hutchinson <[email protected]> 2015-06-20 20:14:00 --- I tried changing the application from /bin/mv to /bin/ln but the files didn't end up being hard-linked. When I tried /bin/ln -s, I got broken links: [maxhutch@cetuslac1 A000]$ ls -ltr total 297216 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 00:58 debug_visc_1.0E-4-0000.f00001 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 00:59 debug_visc_1.0E-4-0000.f00002 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 00:59 debug_visc_1.0E-4-0000.f00003 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:00 debug_visc_1.0E-4-0000.f00004 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:00 debug_visc_1.0E-4-0000.f00005 lrwxrwxrwx 1 maxhutch users 91 Jun 21 01:05 debug_visc_1.0E-4-1000.f00005 -> /gpfs/mira-fs0/projects/alpha-nek/nek-swift/./_concurrent/checkpoints_j-35-R-1-2-0/[0]_/[0] -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:07 debug_visc_1.0E-4-1000.f00006 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:07 debug_visc_1.0E-4-1000.f00007 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:08 debug_visc_1.0E-4-1000.f00008 -rw-r--r-- 1 maxhutch users 33587200 Jun 21 01:08 debug_visc_1.0E-4-1000.f00009 Suggestions? -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 --- Comment #6 from Mihael Hategan <[email protected]> 2015-06-20 20:26:52 --- Sorry, I wasn't suggesting doing anything to /bin/ln. That isn't used by Swift. I was suggesting wrapping the application you have to accept job0-0.checkpoint (or whatever name) instead of job1-0.checkpoint. It is my understanding that you have an implicit app file (a swift log or the swift source would really help here), somewhat like this: app (file ckpointout) f(file ckpointin, string name) { appexec name; } file ck1in <"dummy">; file ck1out <"job0-0.checkpoint">; file ck2in <"job1-0.checkpoint">; file ck2out <"job1-1.checkpoint">; //? ck1out = f(ck1in, "job0"); ck2in = ck1out; ck2out = f(ck2in, "job1"); ... If your app would be able to restart from a checkpoint with any name: app (file ckpointout) f(file ckpointin, string name) { appexec filename(ckpointin) filename(ckpointout) name; } Then you wouldn't need the problematic assignment. You could simply say: ck1out = f(ck1in, "job0"); ck2out = f(ck1out, "job1"); -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 Max Hutchinson <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |LATER --- Comment #7 from Max Hutchinson <[email protected]> 2015-06-22 09:03:44 --- To work around, I could either: 1) Replicate the naming logic in a third place, the bash wrapper, or 2) Change the application code to allow the input (text) and checkpoint (binary) files to have different prefixes I opt-ed for (2), which was fewer lines of code and less likely to insert bugs or break at scale. However, it broke backwards compatibility with the primary nek5000 development branch, which is out of my control. I'd still much prefer a rename, and think it would make life easier and less buggy for swift users in general. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 --- Comment #8 from Mihael Hategan <[email protected]> 2015-07-03 00:52:52 --- (In reply to comment #7)
To work around, I could either: 1) Replicate the naming logic in a third place, the bash wrapper, or 2) Change the application code to allow the input (text) and checkpoint (binary) files to have different prefixes I opt-ed for (2), which was fewer lines of code and less likely to insert bugs or break at scale. However, it broke backwards compatibility with the primary nek5000 development branch, which is out of my control.
I'd still much prefer a rename, and think it would make life easier and less buggy for swift users in general.
So I think my suggestion on #1 is a simple shell script that does the move: #!/bin/bash CHECKPOINT=$1 shift ID=$1 mv $CHECKPOINT "job$ID-0.checkpoint" <actualjob> "$@" And the app declaration would be modified from: <actualjob> id ...; to <jobWrapper> filename(checkpointIn) id ...; This allows you to keep the application code as it is. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=1425 --- Comment #9 from Max Hutchinson <[email protected]> 2015-07-03 06:54:02 --- (In reply to comment #8)
(In reply to comment #7)
To work around, I could either: 1) Replicate the naming logic in a third place, the bash wrapper, or 2) Change the application code to allow the input (text) and checkpoint (binary) files to have different prefixes I opt-ed for (2), which was fewer lines of code and less likely to insert bugs or break at scale. However, it broke backwards compatibility with the primary nek5000 development branch, which is out of my control.
I'd still much prefer a rename, and think it would make life easier and less buggy for swift users in general.
So I think my suggestion on #1 is a simple shell script that does the move:
#!/bin/bash
CHECKPOINT=$1 shift ID=$1 mv $CHECKPOINT "job$ID-0.checkpoint" <actualjob> "$@"
And the app declaration would be modified from:
<actualjob> id ...;
to
<jobWrapper> filename(checkpointIn) id ...;
This allows you to keep the application code as it is.
The actual checkpoint files are much more complicated; the example I gave is highly simplified. A checkpoint entails 256 - 8192 files, each in their own directory, with their names and their directory names zero padded properly. In python, its here: https://github.com/maxhutch/nek-analyze/blob/master/interfaces/nek/files.py#... These naming system is chosen to optimize performance of parallel writes, so, for large scale codes, I don't imagine something like this is that uncommon. The second problem with the script solutions is that the rename takes time. In particular, it would be performed in serial. If I used move instead of link, it could take even longer. Admittedly, an in-swift rename would face these challenges as well, but it could at least be parallelized. -- Configure bugmail: http://bugzilla.mcs.anl.gov/swift/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠mcs.anl.gov