Commit graph

4 commits

Author SHA1 Message Date
Henrik Baard
7f52bca485 Migrating data sometimes leaves emulated unmounted
Sometimes migrating data fails to mount the target
volume after operation is finished.

MoveTask is running in its own thread, copying data
between external card and internal memory.

After copying the data the method "bringOnline" is
run. This method destroys and creates the volumes.

When VolumeBase::create() is run it will notify
MountService, who upon receiving this notification
will send a mount command to mount the new primary
storage.

This command will sometimes run before
setState(State::kUnmounted); is called on the newly
created volume. This will cause the mount command to
fail.

VoldConnector: SND -> {10 volume mount emulated 3 -1}
vold : emulated flags change requires state unmounted or unmountable
vold : emulated user change requires state unmounted or unmountable
vold : emulated mount requires state unmounted or unmountable

Lock bringOnline so no volume commands will be processed
until volumes are (re-)created and have correct state.

Bug: 26322200
Change-Id: I4aba85c226d904c42ae9edcdfec21619218939d6
2016-07-06 15:42:34 -06:00
Elliott Hughes
7e128fbe21 Track rename from base/ to android-base/.
Change-Id: I3096cfa50afa395d8e9a8043ab69c1e390f86ccb
2015-12-04 15:50:53 -08:00
Jeff Sharkey
c86ab6f538 Trim both internal and adopted private storage.
Refactor fstrim code to be encapsulated in unique task object, and
give it option of benchmarking when finished.  Trimming now includes
both storage from fstab and adopted private volumes.  Cleaner timing
stats are logged for each unique volume.

Add wakelock during ongoing async move tasks.  Push disk sysfs path
to framework so it can parse any SD card registers as desired.

Bug: 21831325
Change-Id: I76577685f5cae4929c251ad314ffdaeb5eb1c8bf
2015-07-01 15:53:51 -07:00
Jeff Sharkey
1d6fbcc389 Migrate primary external storage.
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
2015-04-24 16:08:07 -07:00