Clarify what happens with Geo when enabling hashed storage

doc/administration/raketasks/storage.md

@@ -42,6 +42,9 @@ If you find it necessary, you can run this migration script again to schedule mi
 
 Any error or warning will be logged in the sidekiq's log file.
 
+NOTE: **Note:**
+If Geo is enabled, each project that is successfully migrated generates an event to replicate the changes on any **secondary** nodes.
+
 You only need the `gitlab:storage:migrate_to_hashed` rake task to migrate your repositories, but we have additional
 commands below that helps you inspect projects and attachments in both legacy and hashed storage.
 

doc/administration/repository_storage_types.md

@@ -87,7 +87,7 @@ The rollback has to be performed in the reverse order. To get into "Legacy" stat
 you need to rollback Attachments first, then Project.
 
 Also note that if Geo is enabled, after the migration was triggered, an event is generated
-to replicate the operation on any Secondary node. That means the on disk changes will also
+to replicate the operation on any **secondary** node. That means the [on disk changes](#project) will
 need to be performed on these nodes as well. Database changes will propagate without issues.
 
 You must make sure the migration event was already processed or otherwise it may migrate