Man kann nun sicher trefflich drüber diskutieren. Aber meiner Meinung nach gehören transaktionsorientierte BLOBs in eine DB und nicht auf eine HD einer 08/15 Workstation.
Tülich gibts den. Nicht jeder hat zu Hause eine Maschine mit RAID, redundantem Netzteil und einer MTBF von 3ZillardenStunden rumstehen und hätte trotzdem gerne, daß seine Daten so sicher wie möglich auf der Platte landen. Und noch dazu hätte ich gerne, daß meine soeben bearbeiteten Bilder auf der Platte landen bevor der im Hintergrund laufende Prozess seine Videodatei geschrieben hat nur weil das BS das alles in eine Transaktion wursten will.
Dann hast du sie aber, wie du richtig schreibst, doppelt refenziert und eben nicht kopiert. Bei einer Änderung änderst du auch "beide" Versionen. Wenn ich das wollte, bräuchte ich nicht erst eine Kopie anlegen.
Is schon klar.
Da kann ich als Entwickler, nur damit die App halbwegs smooth läuft und nicht ewig auf das commit wartet aus einem Kopiervorgang eine MultiThreaded App machen, die noch dazu auf evt. im Nachhinein aufgetretene Fehler reagieren muß. Nö, danke.
Dann lügt mein Benchmark auf meinen Rechner. Bei meiner alten Gurke bin ich knapp am theoretischen Maximum.
Am Fri, 29 May 2009 01:52:23 +0200 schrieb Axel Schwenke:
Hallo!
Wer will das? Da kommt irgendeine Wurst auf die Idee auf einem Fileserver zwei Datei gleichen Namens aber unterschiedlicher Groß-/Kleinschreibung zu speichern und irgendein Client, der das nicht unterscheiden kann, greift drauf zu.
Mann kann sich das Leben wirklich selber schwer machen.
"Thorsten Oesterlein" schrieb im Newsbeitrag news:ycl4dvhywptr.im826spe62a2$. snipped-for-privacy@40tude.net...
Also wuerde er ein transaktionales Dateisystem zu schaetzen wissen.
Dir scheint es sehr am Verstaendnis zu mangeln. Warum sollte eine andere Transaktion (die der Videodatei) irgendwie in die andere Transaktion (Baum kopieren) verwurstet werden ?
Das passiert doch nur, wenn du das Betriebssystem schreibst. Lass es also lieber.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Am Fri, 29 May 2009 16:05:13 +0200 schrieb Thorsten Oesterlein:
Ich mach mir mal die Ingrid
Da hatte ich wohl einen Denkfehler. Du willst Records locken und refenzieren, geänderte jedoch als Original und Kopie speichern, sehe ich das richtig. Mit welcher Granularität soll das vonstatten gehen?
"Thorsten Oesterlein" schrieb im Newsbeitrag news: snipped-for-privacy@40tude.net...
Nur wenn du das Betriebsystem schreibst.
Bir mir wuerde es den Lock beachten und den modifizierten Sektor woandershin schreiben, damit die Kopie nicht betroffen ist.
Nur wenn du der Betriebssystementwickler bist. Implementiert man transationale Systeme sauber, hat man im Gegebnteil nie mit inkonsistenzen zu kaempfen, sondern weiss sehr genau, ob der Prozess die Aenderungen des vorhergehenden sieht oder nicht.
Beim doppelten Dateibaumkopieren unter Windows ? Nie. Nur wenn du eine in einem einzigen Prozess eine ewig grosse Datei kopierst.
Waere ein Rueckschritt. Wenn ich schon die Hand auf der Maus habe um den Text zu markieren, dann moechte ich ihn auch gleich einfuegen koennen (ohne Kontext-Menu, der Default ist nun einmal 'Paste').
Nope... Da ist normalerweise die 3-Tasten-Emulation eingschaltet, Paste passiert indem man beide Tasten zur gleichen Zeit drueckt.
Genau deshalb regt mich CTRL-C schon immer auf... Warum zum Geier musste MS hier die Kombination zum Abbrechen eines Programmes fuer 'Copy' nehmen? Warum nicht als Qualifier anstatt (wie das bei UNIX ueblich war bis man unbedingt Windows kopieren musste). Eine -Taste hatten die ganz alten PC-Tastaturen auch schon.
Die ganzen CTRL-Kombinationen waren schon vergeben, aber das hat MS natuerlich nicht gekuemmert.
Typische Windows-Bevormundung halt. Wir wissen was gut für dich ist und wenn dir das nicht gefällt ist das Pech für dich.
Ich hab hier z.B. eine Datei TDA1541A.pdf, die heisst so weil das vor dem Punkt so auf dem IC draufsteht. Eine Umbenennung nach Tda1541a.pdf fände ich sehr unpassend.
Es kann jeder halten wie er will, zumindest unter Linux hast du die Option ein FS zu verwenden welches nicht case-sensitive ist (FAT32 oder HFS+ z.B.) oder ein FS welches es ist (HFS+, ext3, XFS,...). Gleiches gilt fuer MacOS X (je nach Optionen bei der Formatierung mit HFS+)
Theoretisch. Aus Sicherheitsgruenden macht z.B. ext3 auf Linux per default alle 5s ein commit und damit die Transaktion zu. Das flusht den Cache um die Reihefolge zu erwingen. Windows wird da auch ein Limit haben um den Schaden bei einem Crash zu begrenzen denke ich.
Interessehalber mal kurz getestet:
---------------------------------------------------------------------- # uname -s -r Linux 2.6.26 # find . -type f | wc -l
24340 # mount | grep /dev/sdb1 /dev/sdb1 on /mnt/pkgsrc type ext3 (rw,barrier=1) # cat /sys/block/sdb/queue/scheduler noop [cfq] ... # sync # time cp -R . /mnt/pkgsrc/test/
real 0m58.446s user 0m0.462s sys 0m4.587s # sync # time cp -R . /mnt/pkgsrc/test/ >/dev/null | cp -R . /mnt/pkgsrc/test2
real 2m9.983s user 0m0.901s sys 0m9.640s
---------------------------------------------------------------------- Ich habe beides ein paar mal laufen lassen (Quelldaten waren also im RAM). Writeback-Cache war an der Zielplatte eingeschaltet. Macht wenig Unterschied ob seriell oder parallel, seriell war auch hier etwas schneller.
Bei Linux wird ja gerade ext4 eingefuehrt, da hatten sie als Default das Commit-Intervall hochgesetzt und die Reihenfolge Daten vor Metadaten nicht mehr erzwungen. Die Leute wollen aber maximale Sicherheit beim Crash, Performance hat niedrigere Prioritaet. Nach Protesten ist man jetzt wohl wieder zurueckgerudert ...
Nein, eben nicht, sondern das wird vom FS erkannt und genau dann die Kopie erst angelegt. Da man sowieso die Aenderung schreiben muss faellt das nicht wirklich auf.
Aber der Sprung ist für das Quant ein alles Bekannte umwälzendes Ereignis. Der Eintritt in eine völlig neue Qualität seiner Existenz.
OK, das gebe ich zu. Ich war da in der Argumentation wohl allzusehr auf Linux fixiert. Das liegt daran, daß ich mit kommerziellen UNIXes kaum was zu tuen habe. Wenn die Leute für das Server-OS löhnen wollen, nehmen sie meist lieber gleich Windows-Server und umgehen damit die Probleme heterogener Landschaften komplett. Auf den Clients läuft nämlich eh' praktisch immer Windows.
Nein. Das größte Problem für Samba ist die Abbildung von ACLs auf die steinzeitliche maschinenlokale UGW-Rechteverwaltung. Da muß immer massiv gefrickelt werden und zwar ganz unabhängig vom Auth-Backend.
Allerdings gebe ich die insofern Recht, daß das nicht so sein müßte. Wenn man nämlich konsequent eine replizierbare Datenbank als Backend verwenden würde und konsequent auf allen Maschinen ACLs zur Rechteverwaltung verwenden würde, dann würde sich der ganze Frickelkram zu einer einfachen und logischen Geschichte auflösen.
Allerdings könnte man dann wohl nur noch viel weniger Supportleistungen verkaufen...
Und es würde außerdem genau das rauskommen, was Windows tut...
Das spielt nur dann eine Rolle, wenn man Samba gemeinsam mit einem Windows-Server (>=2k) verwenden will. Das will man aber meist nicht, weil dann Samba nämlich eigentlich überflüssig ist. OK, oft muß man, weil Exchange-Server gefordert werden. Dann hat man tatsächlich _zusätzlich_ auch noch dieses Problem.
Was ist damit? Wenn festgelegt ist, daß sie halt nicht case sensitive sind, dann sind sie es nicht. Reine Definitionsfrage. Ist z.B. bei Programmiersprachen ganz genauso. C ist case sensitive, Pascal nicht. Allein wegen dieses Sachverhaltes gab es wohl schon Millionen Mannstunden Debugging-Aufwand für C-Programmierer. Beide Ansätze haben IMHO Vor- und Nachteile. Ich persönlich mag bei Filesystemen auch eher case-sensitive, bei Programmiersprachen allerdings bevorzuge ich eindeutig non-case-sensitive.
Aber egal, wie du bereits festgestellt hast, könnte Windows im Prinzip beides. Unix allerdings nicht! (Entsprechende Fähigkeiten müssen z.B. bei Samba erst wieder mühevoll drangefrickelt werden)
Was ist also mächtiger?
Doch. Hardlinks kannte NT von Anfang an. Seit Vista auch symbolische Links. Guten Morgen, habe ich dich jetzt aufgeweckt? Dir wieder ein Argument genommen? Ich bin echt untröstlich...
Unsinn. Das hängt natürlich immer von den Fähigkeiten der verwendeten fs ab. Hardlinks gibt es immer nur innerhalb von fs, die Hardlinks unterstützen. Und symbolische Links gibt es nur aus fs, die sie unterstützen. Zeigen können sie allerdings auch auf Ziele in fs, die keine Ahnung von symbolischen Links haben.
Also ganz genauso wie unter NT. Weil nämlich beide nur mit Wasser kochen können. Jederzeit unterworfen der allmächtigen Kraft der Grundgesetze der Informatik.
Nein. Wenn definiert ist, daß "f" gleich "F" und "o" gleich "O" sein soll, dann ist natürlich "foo" auch gleich "FOO". Das ist ein simple Mengenabbildungsfunktion, die Windows excellent beherrscht, Unix aber nicht.
Bei einer Komplexitätsbetrachtung ist Windows hier eindeutig mächtiger.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.