[VPS] simfs - Wat is dat fysiek? Solid, sparse, dedicated?

[Sando]

Het filesystem gemount op / op mijn VPS is /dev/simfs/, en ik vraag me af wat dat fysiek inhoudt.

VPSsen oversellen over het algemeen hun ruimte. Betekent dat als je een file verwijdert, dat jij voortaan die ruimte kunt gebruiken, of gaat dat meteen naar de eerstvolgende andere gebruiker op de fysieke server/hdd die ruimte nodig heeft?

Gedetailleerder, als ik per ongeluk foto's van je moeder online heb gezet en ze meteen weer verwijder, is deze vrije ruimte dan nog steeds toegekend aan mijn simfs?

Met andere woorden, als je vader eigenaar van de fysieke VPS apparatuur is, kan hij de foto's van je moeder dan nog recoveren als ik
dd if=/dev/zero of=./mijn.eigen.moeder heb gedaan?

Geen Starwars verhalen graag over hoe je iets 234 keer moet overschrijven voordat Joda er niet meer bij kan. De CIA heeft toch geen interesse in foto's van je moeder, scriptkiddie-safe is genoeg. Ik ben gewoon benieuwd of de theoretisch beschikbare ruimte in mijn account ook de ruimte is die ik voorheen gebruikte of dat ik eigenlijk dd doe naar compleet andere fysieke bits.

-edit-

Wellicht ten overvloede; dit is gewoon serieus hoor. Ik heb perongeluk de unencrypted versie van mijn wekelijkse backup upgeload. Mijn pincode staat er niet in, maar categorie liever niet recoverable.

[ Voor 18% gewijzigd door Sando op 06-05-2011 19:54 ]

[Freezerator]

Ligt er voornamelijke in hoe de storage van je vps is geregeld of het makkelijk te recoveren is. Iets recoveren van een raid 10/50 is een stuk lastiger dan van een single disk.

[Sando]

Oh dat wist ik niet, ik dacht dat de onderliggende hardware zelf maar moest uitvechten hoe het de bits opslaat, maar hoe het uiteindelijk aan de (fysieke en dus niet vm - wat nog een laag verder is) machine aangeboden wordt gewoon bit == bit is, waardoor opslaan, verwijderen en recoveren altijd het zelfde is.

Maar als je gelijk hebt dan zal het wel loslopen want de VPS is aangesloten op RAID10 idd.

[Sando]

Ik besef me achteraf dat ik nogal Gregoriaans bezig was met rm en dan dd.

De backup van mijn backup (goed hè! ) staat een paar provincies verderop op een Synologyschijf, en dan volstaat find . -type f -exec shred -fuzn1 '{}' \; (en dan rm -rf voor de dirs)

Maar nog steeds ben ik benieuwd of bytes ook mijn bytes zijn op een simfs.

-edit-

Meh, journaling maakt Gregoriaanse methodes toch noodzakelijk.

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file system modes:

* log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

* file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

* file systems that make snapshots, such as Network Appliance's NFS server

* file systems that cache in temporary locations, such as NFS version 3 clients

* compressed file systems

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount).

In addition, file system backups and remote mirrors may contain copies of the file that cannot be removed, and that will allow a shredded file to be recovered later.

[ Voor 66% gewijzigd door Sando op 07-05-2011 02:42 ]

[mvdster]

simfs is een virtueel filesysteem wat gebruikt wordt door de virtualisatietechniek OpenVZ. In feite wordt onderliggend gewoon ext3 of 4 gebruikt (andere filesystems worden niet ondersteund door OpenVZ). Als je een bestand verwijderd hoef je niet bang te zijn dat een andere container die data kan recoveren hoor.

[Sando]

mvdster schreef op zaterdag 07 mei 2011 @ 15:02:
Als je een bestand verwijderd hoef je niet bang te zijn dat een andere container die data kan recoveren hoor.

Daar ben ik wel blij mee!
Hoedanook, die containers moeten toch sparse zijn, hoe kan een VPStoko anders de boel oversellen?