public int createRecord(Iterable<FileIdIndexedStorage> fileIdIndexedStorages) throws IOException {
    connection.markDirty();

    PersistentFSRecordsStorage records = connection.getRecords();
    if (!FSRecordsImpl.REUSE_DELETED_FILE_IDS) {
      int newRecordId = records.allocateRecord();

      checkNewRecordIsZero(records, newRecordId);

      return newRecordId;
    }

    final int reusedRecordId = connection.reserveFreeRecord();
    if (reusedRecordId < 0) {
      int newRecordId = records.allocateRecord();

      checkNewRecordIsZero(records, newRecordId);

      return newRecordId;
    }
    else {//there is a record for re-use, but let's clean it up first:
      //TODO RC: Actually, it could significantly slow down new record allocation, so it is better to clear all
      //         that async, during free records collection.
      //         We can do that for attributes & content, but we can't do it for fileIdIndexedStorages, since we
      //         don't know the list of FileIdIndexedStorage storages early on -- fileIdIndexedStorages are collected
      //         incrementally, as they are registered.
      //         Actually, by the same reason even current approach is not bulletproof: .createRecord() could be called
      //         _before_ all FileIdIndexedStorage are registered => reusedRecordId in not-yet-registered FileIdIndexedStorage
      //         won't be cleaned.
      //         Alternative solutions could be:
      //         a) Maintain (i.e. persist) list of 'associated storages' inside VFS, and read all them on startup.
      //            Cons: need additional fields in storage header (bytesPerRow) to read the storage content.
      //         b) Clean data associated with removed fileIds on shutdown (when all storages are already registered),
      //            not on startup. Cons: delays shutdown, and increase chance of VFS corruption if app forcibly terminated
      //            due to long shutdown.
      //         c) Don't reuse fileId at all -- just keep allocating new fileIds, and re-build VFS as int32 exhausted
      //            The approach under investigation now (see REUSE_DELETED_FILE_IDS=false feature-flag) probably to be default
      //            in the next releases. Cons: need to monitor fileId exhaustion and schedule VFS rebuild in advance
      deleteContentAndAttributes(reusedRecordId);
      for (FileIdIndexedStorage storage : fileIdIndexedStorages) {
        storage.clear(reusedRecordId);
      }
      records.cleanRecord(reusedRecordId);
      return reusedRecordId;
    }
  }
public int createRecord(Iterable<FileIdIndexedStorage> fileIdIndexedStorages)