以下は(良いアイデアかどうかにかかわらず)動作しないようです。
me@client:~ $ ssh host
me@host:~ $ cd /media/big-hdd
me@host:/media/big-hdd $ sudo fallocate -l 8g swapfile
me@host:/media/big-hdd $ sudo chown me swapfile
me@host:/media/big-hdd $ logout
me@client:~ $ sudo mkdir /media/big-hdd
me@client:~ $ sudo sshfs me@host:/media/big-hdd /media/big-hdd
me@client:~ $ sudo mkswap /media/big-hdd/swapfile
Setting up swapspace version 1, size = 8388604 KiB
no label, UUID=7d6b9704-7692-4463-b0c7-8a94668d715f
me@client:~ $ sudo swapon /media/big-hdd/swapfile
swapon: /media/big-hdd/swapfile: insecure permissions 0644, 0600 suggested.
swapon: /media/big-hdd/swapfile: insecure file owner 1002, 0 (root) suggested.
swapon: /media/big-hdd/swapfile: swapon failed: Invalid argument
誰かが提案した他の場所で問題は実際の割り当てがなく、メモリのみが予約されているInvalid argument
ためです。fallocate
しかし(はるかに遅い)
me@host:/media/big-hdd $ sudo dd if=/dev/zero of=swapfile count=2048 bs=4MiB
何も変わらなかった。
これは原則として不可能ですか、それとも機能しないという間違いを犯しましたか?
答え1
sshfs
これは、ファイルシステムを実装する方法により不可能です。
デフォルトでは、ファイルシステムのクライアント側を一連のsftp
ファイル転送にマッピングします。ファイルをローカルに更新してリモートsshfs
にコピーします(完了)。マニュアルページ自体の内容は次のとおりです。
SSHFSがインストールされているローカルコンピュータでは、実装はユーザースペースのファイルシステム(FUSE)カーネルモジュールを使用します。これにより、エンドユーザーは、自分のコンピュータ上のローカルファイルであるかのように、SSHセキュリティを介して提供されるリモートファイルとシームレスに対話できます。リモートコンピュータでSSHのSFTPサブシステムを使用します。
また、FUSEはユーザースペースで実装されているため、スワップが発生する可能性があることに注意してください。すでにスワップしているシステムに与える影響を考えてみましょう。 FUSEサブシステムが呼び出されますが、実行するには別のプロセスをスワップする必要があります(またはさらに悪いことには、それ自体を再スワップする必要があります)。
これはNFSなどのブロックベースのファイルシステムを介して達成できます。
答え2
驚くべきことに直接動作しません。swapon <swapfile-on-ssh>
どちらもswapon -o loop <swapfile-on-ssh>
失敗しInvalid argument
、swapon: swapfile has holes
ログに表示されます。
ただし、次のように動作できますlosetup
。
losetup -f <swapfile>
losetup # To take a look which device I've got
swapon /dev/loop<N>
私はこのトリックを使ってラズベリー3でgccを構築しました。他の回答(sshfs自体がスワッピングの対象となる可能性がある)に対する懸念がまだあります。