-
Jeff Sharkey authored
When requested, kick off a thread that will migrate storage contents between two locations. This is performed in several steps that also interact with the framework: 1. Take old and new volumes offline during migration 2. Wipe new location clean (10% of progress) 3. Copy files from old to new (60% of progress) 4. Inform framework that move was successful so it can persist 5. Wipe old location clean (15% of progress) Derives a hacky progress estimate by using a rough proxy of free disk space changes while a cp/rm is taking place. Add new internal path for direct access to volumes to bypass any FUSE emulation overhead, and send it to framework. Remove mutex around various exec calls since setexeccon() is already per-thread. Bug: 19993667 Change-Id: Ibcb4f6fe0126d05b2365f316f53e71dc3e79a2b8
1d6fbcc3
