Editing instances

This page shows you how to edit a Filestore instance using either the Cloud Console or the gcloud tool.

Once created, you can modify a Filestore instance in the following ways:

  • Increase its capacity.
  • Decrease its capacity (High Scale SSD instances only).
  • Change its description.
  • Manage IP-based access control rules.
  • Manage labels. (For more information, see Managing labels.)

Scaling capacity

When using Filestore, we recommend that you monitor the utilization of your Filestore instances so that you can adjust capacity as needed. For example, if you notice that a High Scale tier instance no longer needs all of its allocated capacity, you may consider scaling it down. Similarly, if you notice that you are running out of capacity, you may want to scale up capacity to prevent your applications from breaking. You also need to add capacity if the filesystem runs out of inodes. To check if this is the case, run the following command from the client VM:

df -i

The command returns something similar to the following:

Filesystem           Inodes  IUsed      IFree  IUse%  Mounted on
10.0.0.2:/vol1    134217728     13  134217715     1%  /mnt/test

Each file stored on the file share consumes one inode. If the filesystem runs out of inodes, you will not be able to store more files on the file share even if you haven't reached the maximum allocated capacity. The only way to add inodes is by adding capacity. However, reaching the maximum inodes is very rare and is only a concern if you need to store a large number of very small files.

Differences in scaling behavior by service tier

Basic tier instances can only be scaled up by 1 GB increments or its multiples. High Scale tier instances can be scaled up or down by 10 TB increments or its multiples. Scaling an instance does not affect its availability and can be performed while the instance is in use. The following table shows how file share capacity can be scaled based on the service tier:

Service tier Basic HDD Basic SSD High Scale SSD
Scaling direction Up only Up only Up and down
Scaling increment 1GB 1GB 10TB
Minimum capacity 1TB 2.5TB 60TB
Maximum capacity 63.9TB 63.9TB 320TB

Additionally, High Scale SSD tier instances require significantly more time to complete a scaling operation compared to Basic HDD and Basic SSD instances. Scaling up the capacity of a High Scale instance requires 26-48 hours to complete and scaling down requires over 20 hours to complete. The actual time required varies depending on the amount of data stored in the instance and the load on the client VM. To ensure that your instances don't run out of capacity, perform these operations in advance.

When a scaling operation is taking place, you cannot cancel the operation or make any other edits to the instance, but read and write operations are uninterrupted. You also cannot scale a High Scale SSD instance to a capacity level that's below what's needed for storing its existing file data and metadata. Attempting to do so results in an error.

Instructions for editing an instance

Cloud Console

To edit Filestore instances using the Cloud Console, navigate to the Edit instance page, where you can edit the instance description, manage IP-based access control rules, and scale the file share performance:

  1. In the Cloud Console, go to the Filestore Instances page.

    Go to the Filestore instances page

  2. Click the instance ID of the instance you want to edit.

  3. On the Instance details page, click Edit to go to the Edit instance page.

  4. Make changes to the instance description, IP-based access control rules, and capacity as needed. For details, see Creating instances.

  5. Click Save.

gcloud

Before you begin

To use the gcloud tool, you must either install the Cloud SDK or use the Cloud Shell that's built into the Cloud Console:

Go to the Cloud Console

gcloud command for editing an Filestore instance

You can edit a Filestore instance by running the instances update command. If you need to update the configuration rules for IP-based access control, you must use the gcloud beta instances update command with the --flags-file flag and specify a json configuration file. If you choose this method, you do not need to use the --file-share flag because it is already included in the json configuration file:

 gcloud [beta] filestore instances update instance-id
     --[project="project-id"]
     --[zone=zone]
     --[file-share=name="file-share-name",capacity=file-share-size]
     --[description="instance-description"]
     --[flags-file=file-name.json]

where:

  • instance-id is the instance ID of the Filestore instance you want to edit.
  • project-id is the project ID of the Cloud project that contains the Filestore instance. You can skip this flag if the Filestore instance is in the gcloud default project. You can set the default project by running:

     gcloud config set project project-id
    
  • zone is the zone where the Filestore instance resides. Run the gcloud filestore zones list command to get a list of supported zones. You can skip this flag if the Filestore instance is in the gcloud default zone. You can set the default zone by running:

     gcloud config set filestore/zone zone
    
  • file-share-name is the name of the file share that is served from the Filestore instance. File share names cannot be changed after instance creation.

  • file-share-size is the new size you want for the file share. You can specify the file share size in whole numbers using either GB (default) or TB.

    To see your available quota, go to the Quotas page in the Cloud Console:

    Go to the Quotas page

  • instance-description is the optional Filestore instance description.

  • file-name is the name of the json configuration file for IP- based access control.

    Example json configuration file:

     {
    "--file-share":
      {
        "capacity": "4096",
        "name": "my_vol",
        "nfs-export-options": [
          {
            "access-mode": "READ_WRITE",
            "ip-ranges": [
              "10.0.0.0",
              "10.2.0.0"
            ],
            "squash-mode": "ROOT_SQUASH",
            "anon_uid": 1003,
            "anon_gid": 1003
          },
           {
            "access-mode": "READ_ONLY",
            "ip-ranges": [
              "10.0.1.0/28"
            ],
            "squash-mode": "NO_ROOT_SQUASH"
          }
        ],
      }
    }
    

    where:

    • ip-ranges is the IP address or range to grant access to. You can specify multiple IP addresses or ranges by separating them with a comma. Example: 10.0.1.0,10.0.2.0,...
    • access-mode is the access level to grant to the client(s) whose IP address falls within ip-range. It can have the values of READ_WRITE or READ_ONLY. The default value is READ_WRITE.
    • squash-mode can have the values ROOT_SQUASH or NO_ROOT_SQUASH. ROOT_SQUASH removes root level access to the client(s) whose IP address falls within ip-range, while NO_ROOT_SQUASH enables root access. The default value is NO_ROOT_SQUASH.
    • anon_uid is the user ID value that you want to map to anon_uid. The default value is 65534.
    • anon_gid is the group ID value that you want to map to anon_gid. The default value is 65534.
Example

The following example updates the nfs-server instance by increasing the file share size to 3 TB.

 gcloud beta filestore instances update nfs-server --zone=us-central1-c --file-share=name="vol1",capacity=3TB

What's next