カピバラ好きなエンジニアブログ

興味ある技術とか検証した内容を赴くままに書いていきます。カピバラの可愛さこそ至高。

CloudBerry DriveでS3マウントした時のフォルダサイズを調べてみる

経緯

S3は以下のURLでも説明されている通り、上限なしのオブジェクトストレージサービスですが、CloudBerry Driveでマウントされたときに一体どの程度の容量になっているのか確認したことなかったので見てみました。

aws.amazon.com

実施内容

  • 事前準備
  • fsutilコマンドで確認
  • フォルダのプロパティで確認

実施作業

事前準備

今回は以下の4つのパターンを試しました。 f:id:live-your-life-dd18:20191121193816p:plain

上から

①ネットワークドライブとしてS3バケットをマウント

リムーバブルディスクとしてS3バケットをマウント

③ネットワークドライブとしてS3バケット配下のフォルダをマウント

リムーバブルディスクとしてS3バケット配下のフォルダをマウント

という風になっています。

尚、フォルダまで入れた理由は、バケット単位フォルダ単位でサイズは変化するのかを確認するためです。

fsutilコマンドで確認

Windows Serverでドライブの容量を確認する方法はいくつかありますが、まずは公式のfsutilコマンドで確認してみます。

docs.microsoft.com

実行したコマンドはこちらです。

fsutil volume diskFree <ドライブ名>


実際に実行した結果としては、以下のようになりました。

①ネットワークドライブとしてS3バケットをマウント
f:id:live-your-life-dd18:20191121193618p:plain

リムーバブルディスクとしてS3バケットをマウント
f:id:live-your-life-dd18:20191121193656p:plain

③ネットワークドライブとしてS3バケット配下のフォルダをマウント
f:id:live-your-life-dd18:20191121193728p:plain

リムーバブルディスクとしてS3バケット配下のフォルダをマウント
f:id:live-your-life-dd18:20191121193906p:plain

結果を見た限りはマウントされたS3はデータサイズが128TBと認識されていて、バケット・フォルダなどのマウント先にかかわらず、1つのマウントに対して128TBが容量として割り当てられるようです。

ただ、1つ気になるのは何故かリムーバルディスクとしてマウントした2つのドライブでエラーが出てしまっていることです。
公式のページを見ると、ハードディスクドライブに照会して空き容量を確認しているそうなので、なんとなくその照会がうまくいってなさそうな気がします。
こちらはパッと調べても原因がすぐにはわかりそうになかったので、一旦保留にして次にいきます。

フォルダのプロパティで確認

次はエクスプローラからフォルダのプロパティで確認します。
確認した結果はこちら。

①ネットワークドライブとしてS3バケットをマウント
f:id:live-your-life-dd18:20191121195350p:plain

リムーバブルディスクとしてS3バケットをマウント
f:id:live-your-life-dd18:20191121195419p:plain

③ネットワークドライブとしてS3バケット配下のフォルダをマウント
f:id:live-your-life-dd18:20191121195449p:plain

リムーバブルディスクとしてS3バケット配下のフォルダをマウント
f:id:live-your-life-dd18:20191121195505p:plain

プロパティからの確認だと、どのマウント方法でも容量は確認できるようです。
こちらでもやはりマウント先の関わらず128TBを上限として割り当てられているので、CloudBerry DriveでのS3マウント時の最大割り当て容量は128TBで間違いなさそうです。

感想及び所感

EC2にS3をマウントして使用する時点で、128TBも使い切るようなケースはあまりないとは思いますが、仮にそれ以上のデータをアップロードする可能性があった場合、バケット単位でマウントするのではなく、細かくフォルダを作成してマウントするようにしたほうがよいと思います。

個人的に、128TB以上のデータが格納されたS3バケットをマウントした場合、どのようにEC2から見えるのかは興味がありますが、そこまでするのは費用的にも手間的にもやめておきます。