milankostickit / betriebssystemeuebung Goto Github PK

• Template Methoden fixen
  • Einzelne Blöcke schreiben/lesen
  • Mehrere Blöcke schreiben/lesen
• Eigene Klasse erstellen
  • Dokumentation

Wenn das Dateisystem gemountet wird, ist es nicht möglich die Stats zu enthaltenen Dateien mittels ls -l auszulesen. Man bekommt stattdessen lauter Fragezeichen.
Im Log bei der Stat-Abfrage dieser Datei: to do: noch einfügen

How should dmap.set(unnit16_t setAddress) handle a call:

• with an address that is to big.
• where the address is already set.

Wenn die filesystemIO Klasse verwendet wird, um etwas in das Blockdevice zu schreiben, gibt es Fehler.
Diese Fehler sehen je nach IDE etwas anders aus.

Nach der Erzeugung müssen Dateien ins Dateisystem kopiert werden.
Der Ablauf muss durch Benutzung der einzelnen Datenstrukuren implementiert werden.

Wenn eine neue Datei erstellt wird muss ein neuer Eintrag in der Root angelegt werden.
Hierzu muss diese einen "leeren Eintrag" finden. Wie ist dieser markiert?

In createEntry(const char* name) habe ich aktuell angenommen, dass bei leerem Eintrag size < 0 gesetzt. ist.

Work the valgrind log:

==16273== Memcheck, a memory error detector
==16273== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==16273== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==16273== Command: ./mount.myfs DATEISYSTEM logfile m -f -s
==16273==
Containerfile= /vol/cifs/hsfs01/home/ilha1011/.nt/BSLab/BetriebssystemeUebung/DATEISYSTEM
Logfile= /vol/cifs/hsfs01/home/ilha1011/.nt/BSLab/BetriebssystemeUebung/logfile
Mountpoint= /vol/cifs/hsfs01/home/ilha1011/.nt/BSLab/BetriebssystemeUebung/m
==16273== Invalid write of size 1
==16273== at 0x40449E: DMap::DMap() (dmap.cpp:14)
==16273== by 0x401B75: MyFS::MyFS() (myfs.cpp:34)
==16273== by 0x401B03: MyFS::Instance() (myfs.cpp:29)
==16273== by 0x403EFB: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273== Address 0x60d88ef is 0 bytes after a block of size 8,191 alloc'd
==16273== at 0x4C298A0: operator new[](unsigned long) (vg_replace_malloc.c:389)
==16273== by 0x404479: DMap::DMap() (dmap.h:22)
==16273== by 0x401B75: MyFS::MyFS() (myfs.cpp:34)
==16273== by 0x401B03: MyFS::Instance() (myfs.cpp:29)
==16273== by 0x403EFB: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273==
==16273== Syscall param lseek(fd) contains uninitialised byte(s)
==16273== at 0x58A40B0: __lseek_nocancel (syscall-template.S:81)
==16273== by 0x4018F0: BlockDevice::read(unsigned int, char*) (blockdevice.cpp:91)
==16273== by 0x403768: void FilesystemIO::readDevice(unsigned long, SuperBlock&) (filesystemIO.h:67)
==16273== by 0x403320: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:396)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273==
==16273== Syscall param lseek(fd) contains uninitialised byte(s)
==16273== at 0x58A40B0: __lseek_nocancel (syscall-template.S:81)
==16273== by 0x4018F0: BlockDevice::read(unsigned int, char*) (blockdevice.cpp:91)
==16273== by 0x40381C: void FilesystemIO::readDevice<unsigned short*>(unsigned long, unsigned short*&) (filesystemIO.h:67)
==16273== by 0x40333C: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:397)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273==
==16273== Syscall param lseek(fd) contains uninitialised byte(s)
==16273== at 0x58A40B0: __lseek_nocancel (syscall-template.S:81)
==16273== by 0x4018F0: BlockDevice::read(unsigned int, char*) (blockdevice.cpp:91)
==16273== by 0x40381C: void FilesystemIO::readDevice<unsigned short*>(unsigned long, unsigned short*&) (filesystemIO.h:67)
==16273== by 0x403358: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:398)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273==
==16273== Syscall param lseek(fd) contains uninitialised byte(s)
==16273== at 0x58A40B0: __lseek_nocancel (syscall-template.S:81)
==16273== by 0x4018F0: BlockDevice::read(unsigned int, char*) (blockdevice.cpp:91)
==16273== by 0x4038D0: void FilesystemIO::readDevice<fileStats*>(unsigned long, fileStats*&) (filesystemIO.h:67)
==16273== by 0x403374: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:399)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273==
==16273== Invalid read of size 2
==16273== at 0x404B04: FAT::setAll(char*) (fat.cpp:74)
==16273== by 0x4033A9: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:401)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16273==
==16273==
==16273== Process terminating with default action of signal 11 (SIGSEGV)
==16273== Access not within mapped region at address 0x0
==16273== at 0x404B04: FAT::setAll(char*) (fat.cpp:74)
==16273== by 0x4033A9: MyFS::fuseInit(fuse_conn_info*) (myfs.cpp:401)
==16273== by 0x403F0D: wrap_init (wrap.cpp:89)
==16273== by 0x4E465DA: fuse_fs_init (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4A8DB: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E4B894: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E47F9B: fuse_session_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E404E7: fuse_loop (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4E508E6: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.3)
==16273== by 0x4043E5: main (mount.myfs.c:105)
==16273== If you believe this happened as a result of a stack
==16273== overflow in your program's main thread (unlikely but
==16273== possible), you can try to increase the size of the
==16273== main thread stack using the --main-stacksize= flag.
==16273== The main thread stack size used in this run was 8388608.
==16273==
==16273== HEAP SUMMARY:
==16273== in use at exit: 20,534,763 bytes in 24 blocks
==16273== total heap usage: 48 allocs, 24 frees, 20,568,715 bytes allocated
==16273==
==16273== LEAK SUMMARY:
==16273== definitely lost: 139,262 bytes in 2 blocks
==16273== indirectly lost: 0 bytes in 0 blocks
==16273== possibly lost: 19,922,640 bytes in 1 blocks
==16273== still reachable: 472,861 bytes in 21 blocks
==16273== suppressed: 0 bytes in 0 blocks
==16273== Rerun with --leak-check=full to see details of leaked memory
==16273==
==16273== For counts of detected and suppressed errors, rerun with: -v
==16273== Use --track-origins=yes to see where uninitialised values come from
==16273== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)
Segmentation fault

The terminator character is currently intended to be represented by a "-1". Bt this character is saved in an uint_16 (unsigned). So the real value is 65535.
This is a problem because this is an actual address.

Sollen die Zeiten in der Root automatisch aktualisiert werden, oder in den Fuse-Methoden?
In der Root wäre vermutlich praktischer, jedoch spiegelt dies dann vielleicht nicht immer die korrekte Zeit wieder, wenn wir auf die Root zu internen Zwecken zugreifen.

• Geschwindigkeit (Video spielt ohne Artefakte ab)

• myfs (FUSE-Methoden) in progress

  • getAttr
  • open
  • read
  • readDir (?)
  • release
  
  

• dmap

  • get/set-all
  • clear
  • set
  • getFreeBlock
  
  

• fat

  • get/set-all
  • addLastToFAT
  • addToFAT not tested because not used
  • addNextToFAT
  • deleteFromFAT
  • iterateFAT
  • getNext
  
  

• root

  • get/set-all
  • get
  • createEntry
  • deleteEntry
  • update
  • exists
  • getName
  
  

• filesystemIO

• mkfs.myfs
  
  

Aufbau der Tests

Pro Klasse die getestet wird existiert eine Testklasse.
Test_Case(s) sind jeweils für logisch zusammenhängende Methoden angesetzt.
Section(s) innerhalb der Test_Case(s) sind für einzelne Testfälle dieser Methoden gedacht.
Wenn es viele Testfälle zu einer Methode gibt können auch mehrer Section(s) in einem TEST_CASE gebündelt werden wodurch nach der Benennung der unter Test stehenden Methoden mit einem Komma getrennt eine zusammenfassende Beschreibung der Section(s) notiert werden soll.

Benennung

test-Klasse_unter_Test.cpp
TEST_CASE("Klasse_unter_Test.Methode_unter_Test / Klasse_unter_Test.Weitere_Methode_unter_Test, Beschreibung", "[Klasse_unter_Test]")
SECTION("Beschreibung des Einzelnen Testfalls")

Durchführung der Test für Fuse

Die myfs wird in jedem TestCase neu instanziiert. Dadurch können die Fuse-Methoden direkt getestet werden.

Sollen die Datenstrukturen die Daten selbst von der Hardware lesen oder übergeben bekommen?
Selbige Problemstellung beim Speichern.

Dokumentation für Read Only Dateisystem schreiben.
Als Abgabe ist eine PDF Datei gefordert.

• findFreeBlockDMAP(...) --> getFreeBlock(...)
• checkFreeSpace() --> bool isFreeSpace()

Verstehen und fixen der fancy Methoden zum schreiben lesen in mkfs.myfs

Cards can be added to your board to track the progress of issues and pull requests. You can also add note cards, like this one!

Genaue Schnittstellen für unsere Datenstrukturen definieren.

Die Methodendeklarationen sollten alle in fat.h erfolgen.
Die in fat.cpp deklarierte Methode initializeFAT(); ist nicht vorhanden. Vermutlich sollte diese Zeile entfernt werden.

Die in myfs.cpp erwähnten Methoden zu Fuse anschauen:

• fuseGetattr (Metadaten zurückgeben)
• fuseOpen (Datei öffnen)
• fuseRelease (Datei schliessen)
• fuseRead (Daten lesen)
• fuseReaddir
• fuseInit

Unser Verzeichnis kann auch beim Initialisieren/Freigeben der Containerdatei geöffnet bzw. geschlossen werden.

• fuseOpendir
• fuseReleasedir

Bei open und close müssen wir schauen, ob wir speichern müssen, welche Dateien offen sind.

E.g. DMAP_SIZE (*_SIZE in generell)
See TODO findFreeBlockInDMAP()

Code im Projekt bereinigen.
Z.B ungenutzt oder leere Methoden entfernen oder includes...

The method dmap.getAll(char * p) does not write the data of dmapValues into p.

Bei einigen Tests in test-fat steht folgendes:
REQUIRE(memcmp(...));
Da memcmp bei gleichem Inhalt 0 zurückgibt, ergibt sich hiermit als boolean false.
Ist vermutlich nicht so gedacht.

Klassenvariablen sollen mit new erzeugt werden, um auf dem Heap zu landen. D.h. man erhält einen Pointer auf die Variable.
Desweiteren sollen wir für jede Datenstruktur die Variablen im destruktiv löschen.

• dmap
• fat
• root
• filesystemIO
• mkfs.myfs

Die Tests die ich gerade geschrieben habe sind nicht erfolgreich. So wie ich das interpretiere ist es irgendwas mit dem Speicher.
Eventuell müssten nochmal die Tests überprüft werden, ich denke allerdings, dass es an dieser Methode liegt, also sollte sie überprüft werden und ggf gefixt.
(alternativ könnte man auch die Methode addToFAT(int block, int nextBlock), die immer zu dem gegebenen Block den nächsten speichert implementieren)

EmptySpaceSize muss in Superblock noch gesetzt werden: Beim Initialisieren und beim Kopieren der Dateien.

Die stats des Verzeichnisses werden im array gespeichert (an letzter Stelle). Damit diese auch gespeichert und geändert werden können, ist der Eintrag auch in ROOT_ARRAY_SIZE mit eingerechnet. Bei manchen Methoden könnte es vielleicht sinnvoll sein sie auf Dateien zu beschränken und dort also das define NUM_DIR_ENTRIES zu benutzen.

Ist fileInfo ein Rückgabetyp?
Wofür wird fileInfo verwendet bzw. müssen wir es verwenden?

Irgendwie muss man entweder in Root oder in myfs mit unserem Basisverzeichnis umgehen. Dieses muss auch stats besitzen, in denen ein paar Verzeichniseigenschaften stehen, das bei getAttr zurückgegeben wird.

Ich habe gerade in fuseGetattr() eine konvertierung von path zu dessen basename (z.B. "/test.txt" --> "test.txt") implementiert.
Das soll in allen Fuse-Methoden gemacht werden:

• getAttr()
• fuseMakeNod
• fuseUnlink
• fuseRead
• fuseOpen
• fuseWrite
• fuseRelease
• fuseCreate

Wenn ein Eintrag erstellt wird, wird der firstBlock in den fileStats nicht gesetzt. Da der bisher vorhandene Wert aber auf einen Block verweist, sollte man firstBlock vielleicht auf FAT_TERMINATOR setzen.

• Wie soll die Klasse heißen? (Bisher: FilesystemIO)
• Soll die Klasse ihr eigenes Blockdevice erstellen, einen pfad übergeben bekommen oder ein Blockdevice bekommen?

In mkfs.myfs Containerdatei erstellen/öffnen und dort per Methode alle Datenstrukturen erzeugen und initialisieren.

The Methodheads in mkfs.myfs should be moved in a proper header-file.

Die Initialisierung der Datenstrukturen als leer muss beim Erstellen des Dateisystems erfolgen.
Dies sollte innerhalb der einzelnen Datenstrukturen erfolgen.

• DMap
• FAT
• Root

How should dmap.cleat(unnit16_t clearAddress) handle a call with an address that is:

• to big
• to small (negative) -> Because we are using unsigned int this is not really a problem of the implementation.

#include </usr/local/include/osxfuse/fuse.h>
wurde geändert zu
#include <fuse.h>
damit es hoffentlich bei allen funktioniert.
Das muss/kann jetzt noch auf nicht-Linux getestet werden.

• Containerdatei testen (erstellen, lesen, schreiben).
• BUG: Containerdatei ist nicht sichtbar

Sollen wir einen header für alle unsere systemweiten konstanten anlegen?

Ursachen

• Darstellung des letzten Blockes einer Datei als -1 in der FAT Tabelle
• Gespeichert als uint16_t
• Gesamter benötigter Adressraum geht bis 2^16 = 65.536 = uint16_t

Folge

Das Terminator "Symbol" war gleichzeitig ein tatsächlich vorhandene Adresse, wodurch diese immer wieder als folgendes Array angehängt wurde.

(Vorläufige) Lösung des obigen Problems

Vergrößerung des Variablentyps auf uint32_t. Dadurch zeigt die -1 nicht mehr auf eine Tatsächliche Adresse. Dadurch ist die FAT auf 512 Blöcke angewachsen (alle Superblock, DMap und Root zusammen brachen nur 81 Blöcke)

Das Dateisystem, das bei mkfs.myfs erstellt wird, wird nach Ausführen von mount.myfs nicht korrekt gelesen und initialisiert (in fuseInit in myfs.cpp).
Vermutlich irgendein IO fehler.

iterateFAT() sollte eventuell eine list<uint16_t> zurückgeben.
Wenn das geändert wird muss es in .cpp / .h geändert werden.

Ich habe auch an ein paar Stellen in fat.h den Datentyp zu uint16_t geändert.
Genaue Funktionalität/Implementierung ist mir leider nicht bekannt.

One to rule them all.
Oder Fachspezifische Alleinkompetenzen.

In dem Struct fuse_file_info ist ein Attribut fh vorhanden: (aus Dokumentation: File handle. May be filled in by filesystem in open(). Available in all other file operations).
In open() kann man dort einen uint64_t Wert speichern (z.B index der fileStats in root) um die weiteren Methoden zu beschleunigen. Könnten/Sollten wir vielleicht irgendwann mal machen.

Da die FAT jetzt nicht mehr ein vielfaches von 2 an Blöcken verwaltet, muss in der DMap am Ende des Implementierten Speichermodells aufgepasst werden.

Die Größe der Root (in Blöcken) wird im Konstanten-header angegeben.
Da wir nur ein Verzeichis haben und NUM_DIR_ENTRIES = 64 muss die Root 64 filestats enthalten.
Wie viele Blöcke belegt diese dann? (Evtl. etwas mehr Platz beanspruchen, da wir vllt. noch irgendwelche attribute in filestats hinzufügen)

Klassen für jede einzelne Datenstruktur erstellen.

• Superblock (Milan, Hannes)
• DMAP (Milan, Hannes)
• Root (Alex)
• FAT (Joscha)

Ebenfalls eine Klasse für IO-Methoden:

• IO-Methoden

• implement
• check ?

Bei den Variablen sollten wir einheitliche Typen verwenden. Folgende Möglichkeiten sind, bis jetzt, vorhanden:

• u_int...
• uint...
• size_t

Wenn die ...int... Varianten benutzt werden sollen gibt es noch das Problem der Größe (16,32,...512?!?!)