One place for hosting & domains

      How to Update Your Old WordPress Posts With the Block Editor


      Since the Block Editor is now the default tool for creating new WordPress content, site owners are having to address the question of what will happen to their older posts and pages. This content will inevitably need updating since the Classic Editor plugin won’t be around forever.

      Fortunately, there are methods in place for handling this exact situation. If you need to make changes to an old post, you can easily do so without any help from the Classic Editor. This makes it much easier to bring your old and new content into alignment.

      In this post, we’ll discuss the Block Editor (you might know it by its nickname: Gutenberg) and then we’ll show you two methods for updating your old posts using this new tool. Let’s get started!

      Understanding the Differences Between the Classic and Block Editors

      For many years, WordPress users created new content for their websites in a visual editor, now known as the Classic Editor. It consisted primarily of one large field where you could add text, images, and other media.

      The WordPress Classic Editor.

      The main downside to the Classic Editor was that some elements — such as tables and content columns — required coding or extra plugins to implement. This arguably made the publishing process more complicated and time-consuming than it needed to be.

      To address that issue, the Block Editor was created. It enables you to use a system of ‘blocks’ to create content in WordPress. Each block holds a specific type of content, such as a paragraph, an image, a table, a list, or just about any other element you might want to add to a post or page.

      The WordPress Block Editor.

      With blocks, WordPress users can create more complex content without the need for coding. Each block has individual settings so you can customize specific elements. Additionally, you can more easily move content around the page to create columns or other unique layouts.

      Generally speaking, the Classic Editor is considered the ‘simpler’ of the two options because of its interface. There’s just one field where all of your content goes, as opposed to many separate blocks. However, the Block Editor is built for ease-of-use and can be more user-friendly — especially for those new to WordPress.

      Get More with DreamPress

      DreamPress Plus and Pro users get access to Jetpack Professional (and 200+ premium themes) at no added cost!

      Switching Over from the Classic Editor to the Block Editor

      The Block Editor has been ‘live’ since December 2018 and now serves as the default editor for anyone running WordPress 5.0 or later. However, some users have chosen to disable it in order to continue using the old – or Classic – editor.

      If you’ve been using WordPress for some time and are familiar with the Classic Editor, using the Block Editor may not seem very appealing. After all, it still has compatibility issues with some plugins and themes, and learning a new interface isn’t the most fun way to use your time.

      However, there are a few reasons to embrace the change. To start with, the Block Editor should streamline your content creation. Once you get past the learning curve, adding blocks can be much faster than stopping to code a table or columns by hand. More importantly, you may want to make this transition for the sake of your site in the long term. While right now you can keep the Classic Editor in place using a plugin, WordPress plans to stop support for that system eventually.

      For now, support is promised until 2022. However, once updates are no longer being released, having this plugin installed on your site could pose a security risk. At a certain point, moving over to the Block Editor will be in the best interests of your website.

      What the Block Editor Means for Your Existing Content

      Fortunately, old posts and pages created in the Classic Editor are preserved in their current format with the Block Editor. Each one features a single, large block called a Classic block. All of your text, images, and other content will be found inside this block, unchanged.

      A Classic block in the WordPress Block Editor.

      The Block Editor’s effect on your theme and plugins is a little more complicated. There have been compatibility issues between the new editor and some themes and plugins, so it’s possible that enabling it will cause problems on your site.

      In particular, page builders and other plugins that affect the way the WordPress editor looks and functions tend to have trouble with the Block Editor. However, updates have been released for many of these plugins to fix these issues. It’s a good idea to check each of your major plugins (especially any that affect the editor) to see if they are compatible.

      The Block Editor should be useable with just about any theme. That said, it works better with some than with others. Ideally, you’ll want to use a theme that has been updated for use with the Block Editor or a theme that was created after the new editor’s release and built with compatibility in mind.

      The best way to avoid any potential issues is to create a staging version of your site. Then you can thoroughly test for any problems before updating your live site.

      How to Update Your Old WordPress Posts With the Block Editor (2 Methods)

      Of course, you may not want to leave your old WordPress content as-is. Fortunately, you can update your old posts, pages, and other content types in the Block Editor. There are two primary methods you can use, and each has its pros and cons.

      Before you can use either of them, you’ll need to make sure you have the Block Editor enabled. For most sites, this is already the case.  In other words, if your site is up-to-date and you haven’t done anything to disable the Block Editor, it should be currently active. Therefore, you won’t need to do anything.

      Otherwise, either deactivate the Classic Editor plugin or upgrade to WordPress 5.0 or above to automatically switch your site over to the new editor. Then, you can use one of the following two techniques to work on your existing content.

      Method 1: Continue Editing Your Posts in a Classic Block

      As we described earlier, existing posts and pages will be converted into Classic blocks. If you want, you can edit your content inside these blocks, just as you would in the Classic Editor.

      All you have to do is open the post you wish to update, and click on the Classic block. When you do, you’ll see the TinyMCE toolbar appear at the top of the block. It should look very familiar.

      A Classic block in the Block Editor with the TinyMCE toolbar.

      You can edit within this block exactly as you would in the Classic Editor. If you need to access the Text Editor, you can do so by clicking on the three-dot icon to the right of the toolbar, and selecting Edit as HTML.

      The Edit as HTML option in the Classic block.

      When you select this option, the block’s content will be shown as code, and you can edit it as needed.

      Editing a Classic block in HTML.

      To return to the Visual Editor, simply click on the three-dot icon again and select Edit Visually. That should be all you need to update your old posts using the Classic block.

      Method 2: Convert Your Old Content into Blocks

      The other option you have available is to convert a post or page’s Classic block into new blocks. This will divide up your content up into individual elements, just as if you had created it using the Block Editor.

      To do this, click on the three-dot icon and select Convert to Blocks.

      Selecting the Convert to Blocks option in a Classic block.

      Your post should then split up into separate pieces. Each paragraph will become its own block, as will every heading, image, list, video, button, and element.

      An old Classic Editor post converted into new blocks.

      You can click on an individual block to edit the content within it. While this process usually goes off without a hitch, you’ll want to make sure that each element of your post has converted to the correct type of block.

      For example, if a pull quote from your old post has converted into a regular paragraph block, you can change it by clicking on the leftmost icon in the block toolbar.

      The Change Block Type option in a block.

      You can then select the correct block type from the options listed. Once all of your blocks are set to the correct types, you can use the toolbar at the top of each to make any specific changes related to alignment and placement within the post. You can also make edits related to each block’s type, such as by altering text styling or image size. In other words, you can now use the Block Editor’s full range of capabilities to work on your content.

      New Kid on the Block (Editor)

      Updating old posts is a smart way to freshen up your content and give your site a facelift. If you’re worried about how your old posts will fare in the age of the Block Editor, however, never fear. You can easily make changes to your old posts and pages.

      While you’re updating your WordPress site, why not upgrade your hosting service too? Our DreamPress plans include 24/7 WordPress support to help with all your Block Editor questions.



      Source link

      Deploy Persistent Volume Claims with the Linode Block Storage CSI Driver


      Updated by Linode Written by Linode Community

      What is the Linode Block Storage CSI Driver?

      The Container Storage Interface (CSI) defines a standard that storage providers can use to expose block and file storage systems to container orchestration systems. Linode’s Block Storage CSI driver follows this specification to allow container orchestration systems, like Kubernetes, to use Block Storage Volumes to persist data despite a Pod’s lifecycle. A Block Storage Volume can be attached to any Linode to provide additional storage.

      Before You Begin

      • This guide assumes you have a working Kubernetes cluster running on Linode. You can deploy a Kubernetes cluster on Linode in the following ways:

        1. Use Linode’s k8s-alpha CLI to deploy a Kubernetes cluster via the command line.

        2. Deploy a cluster using Terraform and the Linode Kubernetes Terraform installer.

        3. Use kubeadm to manually deploy a Kubernetes cluster on Linode. You can follow the Getting Started with Kubernetes: Use kubeadm to Deploy a Cluster on Linode guide to do this.

        Note

        • If using the k8s-alpha CLI or the Linode Kubernetes Terraform installer methods to deploy a cluster, you can skip the Installing the CSI Driver section of this guide, since it will be automatically installed when you deploy a cluster.

          Move on to the Attach a Pod to the Persistent Volume Claim section to learn how to consume a Block Storage volume as part of your deployment.

      • The Block Storage CSI supports Kubernetes version 1.13 or higher. To check the version of Kubernetes you are running, you can issue the following command:

        kubectl version
        

      Installing the CSI Driver

      Create a Kubernetes Secret

      A secret in Kubernetes is any token, password, or credential that you want Kubernetes to store for you. In the case of the Block Storage CSI, you’ll want to store an API token, and for convenience, the region you would like your Block Storage Volume to be placed in.

      Note

      Your Block Storage Volume must be in the same data center as your Kubernetes cluster.

      To create an API token:

      1. Log into the Linode Cloud Manager.

      2. Navigate to your account profile by clicking on your username at the top of the page and selecting My Profile. On mobile screen resolutions, this link is in the sidebar navigation.

      3. Click on the API Tokens tab.

      4. Click on Add a Personal Access Token. The Add Personal Access Token menu appears.

      5. Provide a label for the token. This is how you will reference your token within the Cloud Manager.

      6. Set an expiration date for the token with the Expiry dropdown.

      7. Set your permissions for the token. You will need Read/Write access for Volumes, and Read/Write access for Linodes.

      8. Click Submit.

      Your access token will appear on the screen. Copy this down somewhere safe, as once you click OK you will not be able to retrieve the token again, and will need to create a new one.

      Once you have your API token, it’s time to create your secret.

      1. Run the following command to enter your token into memory:

        read -s -p "Linode API Access Token: " LINODE_TOKEN
        

        Press enter, and then paste in your API token.

      2. Run the following command to enter your region into memory:

        read -p "Linode Region of Cluster: " LINODE_REGION
        

        You can retrieve a full list of regions by using the Linode CLI:

        linode-cli regions list
        

        For example, if you want to use the Newark, NJ, USA data center, you would use us-east as your region.

      3. Create the secret by piping in the following secret manifest to the kubectl create command. Issue the following here document:

        cat <<EOF | kubectl create -f -
        
      4. Now, paste in the following manifest and press enter:

        apiVersion: v1
        kind: Secret
        metadata:
          name: linode
          namespace: kube-system
        stringData:
          token: "$LINODE_TOKEN"
          region: "$LINODE_REGION"
        EOF
        

      You can check to see if the command was successful by running the get secrets command in the kube-system namespaces and looking for linode in the NAME column of the output:

      kubectl -n kube-system get secrets
      

      You should see output similar to the following:

      NAME                                             TYPE                                  DATA   AGE
      ...
      job-controller-token-6zzkw                       kubernetes.io/service-account-token   3      43h
      kube-proxy-token-td7k8                           kubernetes.io/service-account-token   3      43h
      linode                                           Opaque                                2      42h
      ...
      

      You are now ready to install the Block Storage CSI driver.

      Apply CSI Driver to your Cluster

      To install the Block Storage CSI driver, use the apply command and specify the following URL:

      kubectl apply -f https://raw.githubusercontent.com/linode/linode-blockstorage-csi-driver/master/pkg/linode-bs/deploy/releases/linode-blockstorage-csi-driver-v0.0.3.yaml
      

      The above file concatenates a few files needed to run the Block Storage CSI driver, including the volume attachment, driver registration, and provisioning sidecars. To see these files individually, visit the project’s GitHub repository.

      Once you have the Block Storage CSI driver installed, you are ready to provision a Persistent Volume Claim.

      Create a Persistent Volume Claim

      Caution

      The instructions in this section will create a Block Storage volume billable resource on your Linode account. A single volume can range from 10 GiB to 10,000 GiB in size and costs $0.10/GiB per month or $0.00015/GiB per hour. If you do not want to keep using the Block Storage volume that you create, be sure to delete it when you have finished the guide.

      If you remove the resources afterward, you will only be billed for the hour(s) that the resources were present on your account. Consult the Billing and Payments guide for detailed information about how hourly billing works and for a table of plan pricing.

      A Persistent Volume Claim (PVC) consumes a Block Storage Volume. To create a PVC, create a manifest file with the following YAML:

      pvc.yaml
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: pvc-example
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
        storageClassName: linode-block-storage

      This PVC represents a Block Storage Volume. Because Block Storage Volumes have a minimum size of 10 gigabytes, the storage has been set to 10Gi. If you choose a size smaller than 10 gigabytes, the PVC will default to 10 gigabytes.

      Currently the only mode supported by the Linode Block Storage CSI driver is ReadWriteOnce, meaning that it can only be connected to one Kubernetes node at a time.

      To create the PVC in Kubernetes, issue the create command and pass in the pvc.yaml file:

      kubectl create -f pvc.yaml
      

      After a few moments your Block Storage Volume will be provisioned and your Persistent Volume Claim will be ready to use.

      You can check the status of your PVC by issuing the following command:

      kubectl get pvc
      

      You should see output like the following:

      NAME          STATUS   VOLUME                 CAPACITY   ACCESS MODES   STORAGECLASS           AGE
      pvc-example   Bound    pvc-0e95b811652111e9   10Gi       RWO            linode-block-storage   2m
      

      Now that you have a PVC, you can attach it to a Pod.

      Attach a Pod to the Persistent Volume Claim

      Now you need to instruct a Pod to use the Persistent Volume Claim. For this example, you will create a Pod that is running an ownCloud container, which will use the PVC.

      To create a pod that will use the PVC:

      1. Create a manifest file for the Pod and give it the following YAML:

        owncloud-pod.yaml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        
        apiVersion: v1
        kind: Pod
        metadata:
          name: owncloud
          labels:
            app: owncloud
        spec:
          containers:
            - name: owncloud
              image: owncloud/server
              ports:
                - containerPort: 8080
              volumeMounts:
              - mountPath: "/mnt/data/files"
                name: pvc-example
          volumes:
            - name: pvc-example
              persistentVolumeClaim:
                claimName: pvc-example

        This Pod will run the owncloud/server Docker container image. Because ownCloud stores its files in the /mnt/data/files directory, this owncloud-pod.yaml manifest instructs the ownCloud container to create a mount point at that file path for your PVC.

        In the volumes section of the owncloud-pod.yaml, it is important to set the claimName to the exact name you’ve given your PersistentVolumeClaim in its manifest’s metadata. In this case, the name is pvc-example.

      2. Use the create command to create the ownCloud Pod:

        kubectl create -f owncloud-pod.yaml
        
      3. After a few moments your Pod should be up and running. To see the status of your Pod, issue the get pods command:

        kubectl get pods
        

        You should see output like the following:

        NAME       READY   STATUS    RESTARTS   AGE
        owncloud   1/1     Running   0          2m
        
      4. To list the contents of the /mnt/data/files directory within the container, which is the mount point for your PVC, issue the following command on your container:

        kubectl exec -it owncloud -- /bin/sh -c "ls /mnt/data/files"
        

        You should see output similar to the following:

        admin  avatars  files_external  index.html  owncloud.db  owncloud.log
        

        These files are created by ownCloud, and those files now live on your Block Storage Volume. The admin directory is the directory for the default user, and any files you upload to the admin account will appear in this folder.

      To complete the example, you should be able to access the ownCloud Pod via your browser. To accomplish this task, you will need to create a Service.

      1. Create a Service manifest file and copy in the following YAML:

        owncloud-service.yaml
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        
        kind: Service
        apiVersion: v1
        metadata:
          name: owncloud
        spec:
          selector:
            app: owncloud
          ports:
          - protocol: TCP
            port: 80
            targetPort: 8080
          type: NodePort

        Note

        The service manifest file will use the NodePort method to get external traffic to the ownCloud service. NodePort opens a specific port on all cluster Nodes and any traffic that is sent to this port is forwarded to the service. Kubernetes will choose the port to open on the nodes if you do not provide one in your service manifest file. It is recommended to let Kubernetes handle the assignment. Kubernetes will choose a port in the default range, 30000-32767.

        Alternatively, you could use the LoadBalancer service type, instead of NodePort, which will create Linode NodeBalancers that will direct traffic to the ownCloud Pods. Linode’s Cloud Controller Manager (CCM) is responsible for provisioning the Linode NodeBalancers. For more details, see the Kubernetes Cloud Controller Manager for Linode repository.

      2. Create the service in Kubernetes by using the create command and passing in the owncloud-service.yaml file you created in the previous step:

        kubectl create -f owncloud-service.yaml
        
      3. To retrieve the port that the ownCloud Pod is listening on, use the describe command on the newly created Service:

        kubectl describe service owncloud
        

        You should see output like the following:

        Name:                     owncloud
        Namespace:                default
        Labels:                   <none>
        Annotations:              <none>
        Selector:                 app=owncloud
        Type:                     NodePort
        IP:                       10.106.101.155
        Port:                     <unset>  80/TCP
        TargetPort:               8080/TCP
        NodePort:                 <unset>  30068/TCP
        Endpoints:                10.244.1.17:8080
        Session Affinity:         None
        External Traffic Policy:  Cluster
        Events:                   <none>
        

        Find the NodePort. In this example the port is 30068.

      4. Now you need to find out which Node your Pod is running on. Use the describe command on the Pod to find the IP address of the Node:

        kubectl describe pod owncloud
        

        You should see output like the following:

        Name:               owncloud
        Namespace:          default
        Priority:           0
        PriorityClassName:  <none>
        Node:               kube-node/192.0.2.155
        Start Time:         Mon, 22 Apr 2019 17:07:20 +0000
        Labels:             app=owncloud
        Annotations:        <none>
        Status:             Running
        IP:                 10.244.1.17
        

        The IP address of the Node in this example is 192.0.2.155. Your ownCloud Pod in this example would be accessible from http://192.9.2.155:30068.

      5. Navigate to the URL of the Node, including the NodePort you looked up in a previous step. You will be presented with the ownCloud log in page. You can log in with the username admin and the password admin.

      6. Upload a file. You will use this file to test the Persistent Volume Claim.

      7. The Persistent Storage Claim has been created and is using your Block Storage Volume. To prove this point, you can delete the ownCloud Pod and recreate it, and the Persistent Storage Claim will continue to house your data:

        kubectl delete pod owncloud
        
        kubectl create -f owncloud-pod.yaml
        

        Once the Pod has finished provisioning you can log back in to ownCloud and view the file you previously uploaded.

      You have successfully You have successfully created a Block Storage Volume tied to a Persistent Volume Claim and have mounted it with a container in a Pod.

      Delete a Persistent Volume Claim

      To delete the Block Storage volume created in this guide:

      1. First, delete the ownCloud Pod:

        kubectl delete pods owncloud
        
      2. Then, delete the persistent volume claim:

        kubectl delete pvc pvc-example
        

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      How to Use Block Storage with Your Linode


      Updated by Linode

      Written by Linode


      Use promo code DOCS10 for $10 credit on a new account.

      How to Use Block Storage with Your Linode

      Linode’s Block Storage service allows you to attach additional storage volumes to your Linode. A single volume can range from 10 GiB to 10,000 GiB in size and costs $0.10/GiB per month. They can be partitioned however you like and can accommodate any filesystem type you choose. Up to eight volumes can be attached to a single Linode, be it new or already existing, so you do not need to recreate your server to add a Block Storage Volume.

      The Block Storage service is currently available in the Dallas, Fremont, Frankfurt, London, Newark, and Singapore data centers.

      Caution

      • Linode’s backup services do not cover Block Storage Volumes. You must execute your own backups for this data.

      • Your Linode must be running in Paravirtualization mode. Block storage currently does not support Full-virtualization.

      How to Add a Block Storage Volume to a Linode

      This guide assumes a Linode with the root disk mounted as /dev/sda and swap space mounted as /dev/sdb. In this scenario, the Block Storage Volume will be available to the operating system as /dev/disk/by-id/scsi-0Linode_Volume_EXAMPLE, where EXAMPLE is a label you assign the volume in the Linode Manager. Storage volumes can be added when your Linode is already running, and will show immediately in /dev/disk/by-id/.

      Add a Volume from the Linode Dashboard

      1. Go to the page of the Linode to which you want to attach a Block Storage Volume.

        Select a Linode from the Manager

      2. Click on the Volumes tab, then click Add a Volume:

        Click Add a Volume

      3. Assign the Block Storage Volume a label and size. The label can be up to 32 characters long and consist only of ASCII characters a-z; 0-9.-_. The maximum volume size is 10,000 GiB. When finished, click Submit:

        Create a Volume with a label.

        Note

        There is currently a soft limit of 100 TB of Block Storage Volume per account.

      4. Once you add a volume it will appear under Attached Volumes with the new volume’s label, size, and file system path.

        A Volume has been created

      5. You’ll need to create a filesystem in your new volume. If your Linode is not already running, boot then SSH into your Linode and execute the following command, where FILE_SYSTEM_PATH is your volume’s file system path:

        mkfs.ext4 FILE_SYSTEM_PATH
        
      6. Once the volume has a filesystem, you can create a mountpoint for it:

        mkdir /mnt/BlockStorage1
        
      7. You can then mount the new volume:

        mount FILE_SYSTEM_PATH /mnt/BlockStorage1
        
      8. If you want to mount the new volume automatically every time your Linode boots, you’ll want to add the following line to your /etc/fstab file:

        FILE_SYSTEM_PATH /mnt/BlockStorage1 ext4 defaults 0 2
        

      Attach a Volume from Your Account’s Volume List

      1. Click on the Volumes page of the Linode Manager to see your account’s volume list:

        View your available Volumes

      2. Click the menu option (three dots) for the volume you want to attach to a Linode and select Attach:

        Open volume menu.

      3. Select the label of the Linode you want to attach the volume to from the dropdown menu, then click Save:

        Attach a Volume to a Linode

        Note

        The Linodes available in this dropdown menu all share the same region as your volume.

      4. You’ll need to create a filesystem in your new volume. If your Linode is not already running, boot then SSH into your Linode and execute the following command, where FILE_SYSTEM_PATH is your volume’s file system path:

        mkfs.ext4 FILE_SYSTEM_PATH
        
      5. Once the volume has a filesystem, you can create a mountpoint for it:

        mkdir /mnt/BlockStorage1
        
      6. You can then mount the new volume, where FILE_SYSTEM_PATH is your volume’s file system path:

        mount FILE_SYSTEM_PATH /mnt/BlockStorage1
        
      7. If you want to mount the new volume automatically every time your Linode boots, you’ll want to add the following line to your /etc/fstab file:

        FILE_SYSTEM_PATH /mnt/BlockStorage1
        

      How to Detach a Block Storage Volume from a Linode

      1. Go back to the page of the Linode which the volume is attached to. Shut down the Linode.

      2. When the Linode is powered off, click on the Volumes tab, then click Detach under the volume’s menu (three dots):

        Detach a Volume from a Linode from the Volume menu.

      3. A confirmation screen appears and explains that the volume will be detached from the Linode. Click Detach to confirm:

        Linode Manager detach volume confirmation

        The Linode’s dashboard does not show the volume present anymore:

        The Linode's Volumes tab shows no attached volumes.

        The volume still exists on your account and you can see it if you view the Volumes page:

        Volume not attached, but still exists.

      How to Delete a Block Storage Volume

      Caution

      The removal process is irreversible, and the data will be permanently deleted.

      1. Shut down the attached Linode.

      2. Detach the volume as described above.

      3. Click the volume’s Delete option on the Volumes page.

        Delete a Volume

      How to Resize a Block Storage Volume

      Storage volumes cannot be sized down, only up. Keep this in mind when sizing your volumes.

      1. Shut down your Linode.

      2. Click the Resize option for the volume you want to resize.

        Select Resize from the Volume menu.

      3. Enter the new volume size. The minimum size is 10 GiB and maximum is 10,000 GiB. Then click Submit.

        Resize Volume menu.

      4. You’ll be returned to the volume list and the notification bell in the top right of the page will notify you when the resizing is complete.

        Notification bell shows the Volume has been resized.

      5. Reboot your Linode.

      6. Once your Linode has restarted, make sure the volume is unmounted for safety:

        umount /dev/disk/by-id/scsi-0Linode_Volume_BlockStorage1
        
      7. Assuming you have an ext2, ext3, or ext4 partition, resize it to fill the new volume size:

        resize2fs /dev/disk/by-id/scsi-0Linode_Volume_BlockStorage1
        
      8. Mount it back onto the filesystem:

        mount /dev/disk/by-id/scsi-0Linode_Volume_BlockStorage1 /mnt/BlockStorage1
        

      Where to Go From Here?

      Need ideas for what to do with space? We have several guides which walk you through installing software that would make a great pairing with large storage volumes:

      Install Seafile with NGINX on Ubuntu 16.04

      Install Plex Media Server on Ubuntu 16.04

      Big Data in the Linode Cloud: Streaming Data Processing with Apache Storm

      Using Subsonic to Stream Media From Your Linode

      Install GitLab on Ubuntu 14.04

      Join our Community

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link