Twarde fluszowanie buforów

Dawno nie było "twardego" wpisu...

Gdy tworzymy aplikację i kod zapisujący do pliku, zwykle traktujemy operację zapisu jako wykonaną gdy sterowanie w kodzie przejdzie do kolejnych instrukcji. Zazwyczaj to fałszywe poczucie bezpieczeństwa w niczym nie przeszkadza. Do czasu, gdy pojawi się sytuacja awaryjna: aplikacja, system operacyjny, dyski lub zasilanie padną.

Odkrywamy jednak operację typu (f)flush() i czujemy się lepiej, bufory mamy opróżnione. Bardzo miło, ale nasza sytuacja w razie awarii systemu nie jest wiele lepsza. Jedyne co osiągnęliśmy, to wypchnięcie danych z jednych buforów do drugich (OS). Dane nadal nie są utrwalone. Jeśli oprogramowanie zapisuje krytyczne dane, realizuje jakąś transakcję, to kiepsko to wygląda.

Aby je utrwalić na nośnikach, musimy sięgnąć po fsync(). Bardzo ładnie jest to wyjaśnione tutaj.

Oczywiście, one nadal nie muszą być utrwalone. Jest jeszcze sterownik systemu plików, sterownik urządzenia blokowego, bufor w macierzy/kontrolerze dysków i w samym dysku! Ale jeśli sterowniki, kontroler dysków i firmware dysku są OK, no to w końcu czujemy się lepiej. Problem w tym, że nie zawsze są OK.

Poza tym, nawet jeśli są OK, awaria dysku/zasilania może przyjść w trakcie zapisywania danych na dysk i zapiszą się tylko częściowo i nie w tej kolejności, w której były zlecone. Implikacje mogą być bardzo daleko idące i dotyczą głównie implementacji: systemów plików, baz danych, systemów transakcyjnych, systemów kolejkowych czy nawet serwera pocztowego. Na pewno wszędzie, gdzie liczy się ACID.

Niektóre systemy udostępniają dodatkowe możliwość wpłynięcia na proces utrwalania, np. Mac OS X udostępnia w fnctl() opcję F_FULLFSYNC. Również Windows udostępnia funkcję FlushFileBuffers() do czyszczenia (całego) cache dysku oraz tryb otwarcia pliku FILE_FLAG_WRITE_THROUGH, których opis sugeruje, że załatwiają sprawę (głowy nie dam, ale wg tego porównania wypada nieźle).

Istnieją narzędzia, które świadomie korzystają z tego dobrodziejstwa, np.:

• SQLite (trop)
• patch do Erlanga (uwzględnione) przysłany przez CouchDB
• ActiveMQ (kod)
• H2 DB udostępnia, ale domyślnie świadomie rezygnuje (analiza)

Istnieją ponadto techniki radzenia sobie z częściowym utrwaleniem danych na podsystemie dyskowym w aplikacjach, które przepisują daną "w miejscu". Dla przykładu Websphere MQ zapisuje dziennik operacji (journal) w stronach i może się zdarzyć, że strona nie jest pełna. Wówczas zapisywana jest część strony, a reszta zostaje dopisana później. Ta druga operacja potencjalnie może skutkować utratą danych tego pierwszego zapisu. Aby to obejść, Websphere MQ domyślnie stosuje dla loga operacji metodę zapisu (LogWriteIntegrity) TripleWrite. Powoduje to dla niepełnych stron loga zapis pierwszej "połówki", na kolejnej stronie commit drugiej "połówki", a następnie (trzeci zapis) commit obu połówek razem do tej pierwszej strony.

To na ostateczne popsucie humoru:

• znacie programistów krytycznych aplikacji biznesowych ;) w Java, którzy świadomie robią coś więcej niż flush() by utrwalić dane?
• znacie kogoś, kto ma transakcyjną bazę danych SQL lub serwer SMTP na "oszukujących" dyskach SATA? (co lepsze, te low-endowe dyski mają duże 16-64MB cache)
• co się stanie z e-mailem, gdy serwer SMTP potwierdzi jego przyjęcie i nie zrobi fsync() na pliku w spoolu, po czym padnie zasilanie?
• znacie administratorów Linux, którzy świadomie wyłączają write cache na dyskach? (czasami robią to za nich same kontrolery macierzowe)
• zastanawialiście się co czeka system plików w wirtualnej maszynie po padzie hosta, zwłaszcza gdy ów filesystem gościa jest plikiem na systemie hosta? (hint)
• czy Wasz system plików księguje (journalling) dane, czy tylko metadane?
• ile lat temu pojawiło się wsparcie dla wiarygodnego utrwalania danych w Twoich krytycznych aplikacjach i systemach?

Wydano FreeBSD 9.0

Nie miałem ostatnio czasu na aktualizację bloga. Teraz aktualizuję go tylko dzięki prokrastynacji bo mam inną ważną robotę. ;-)

Wydano właśnie FreeBSD 9.0. W środku mamy kilka ciekawostek, m.in.:

• softupdates journalling i nowszy ZFS
• HAST, którym kiedyś już pisałem
• zapowiadany Capsicum, nowe algorytmy TCP mod_cc(9)
• High Performance SSH (o, tego nie znałem)
• nowe API rozliczania zasobów (RACCT)
• hhok(9) API do wpinania się w różne miejsca jądra
• sniffer ruchu na USB: usbdump(8)
• ipfw wspiera skoki z powrotem (call, return), co daje interesujące możliwości pisania reguł firewalla
• wsparcie dla prefiksu IPv4 /31 (RFC 3021)
• h_ertt(9) mierzący RTT przelatującego ruchu (DIFFUSE)
• ng_netflow wspiera NetFlow v9
• i inne.

Poza tym w przyszłości pojawią się kolejne ciekawostki:

• CTL (CAM Target Layer), umożliwiający wystawianie np. pliku lub urządzenia blokowego jako LUN
• auditdistd, rozproszone logowanie z jądra do analizy powłamaniowej (grant dla pjd@)

BSD Hypervisor

Zupełnie przypadkiem zauważyłem ostatnio, że pod skrzydłami FreeBSD rozwija się nowy twór ;) w postaci natywnego hypervisora: BHyVe. Projekt jest podarunkiem od NetApp i ma ambitne cele, m.in. wsparcie dla live migration. BHyVe można sklasyfikować jako hypervisor typu hosted, tj. pracujący w otoczeniu systemu operacyjnego (w odróżnieniu od bare metal).

Po co to komu, skoro jest już tyle innych i dojrzałych rozwiązań do wirtualizacji? Syndrom NIH? A może polityka i przykład strategicznego planowania? Czas pokaże. ;-)

DIFFUSE

Naukowcy z CAIA wkładają ostatnio sporo wysiłku w ciekawe usprawnienia FreeBSD. Prócz wspomnianych niedawno modularnej implementacji obsługi różnych algorytmów unikania natłoku w TCP czy modułu siftr(4), pracują również nad klasyfikacją ruchu w firewallu na podstawie danych statystycznych: DIFFUSE.

With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) to classify flows into classes.

Co więcej, rozwiązanie ma wspierać konfigurację rozproszoną—jeden węzeł klasyfikuje, a inne na tej podstawie firewallują.

Projekt (współfinansowany przez Cisco) jest na razie w fazie intensywnego rozwoju, dostępny jako łaty do 9-CURRENT.

Mieszanie w TCP na FreeBSD

Wspominałem kilka miesięcy temu o nowych algorytmach unikania natłoku w stosie TCP we FreeBSD. Niestety, informacje były wówczas szczątkowe. Dziś ukazał się post Summary of Five New TCP Congestion Control Algorithms Project rzucający nieco więcej światła na to rozwiązanie. Warto zwrócić uwagę, że jednym z produktów jest wprowadzenie frameworku Khelp/Hhook (którego innych zastosowań chwilowo nie widzę, ale na pewno ktoś coś fajnego wymyśli;)) i że istniejąca implementacja NewReno została wyniesiona do ładowalnego modułu na równi z nowymi.

Na marginesie, ukazały się także niedawno nowe wydania FreeBSD: 7.4 (legacy) i 8.2. Pojawił się np. moduł ng_patch(4), umożliwiający toporne modyfikowanie pakietów w locie (operacje arytmetyczne i bitowe). Inna ciekawostka to moduł siftr(4), zapisujący do pliku dane statystyczne o połączeniach TCP. Szkoda, że nie mam czasu przyjrzeć im się bliżej. :(

Co słychać we FreeBSD w 2010Q3?

Niedawno pojawił się kolejny FreeBSD Quarterly Status Report. Co tam ciekawego? A, to zależy, co dla kogo jest ciekawe. ;)

Ja zwracam uwagę np. na:

• postępy w projekcie Ringmap, o którym pisałem wcześniej
• postepy w migracji z GCC na CLANG, podobne ruchy można zresztą zaobserwować w Linuksie
• postępy w implementacji FreeBSD Services Control (fsc), odpowiednika Solaris Service Management Facility, Upstart itp. zamienników initd
• nowe moduły dla BSNMP (np. SNMPv3, WLAN)
• 5 nowych (w odniesieniu do New Reno) algorytmów unikania przeciążenia w TCP: CUBIC, HTCP, Vegas, HD and CHD (oparte o śledzenie opóźnień w transmisji, a nie tylko strat)
• framework Capsicum rozszerzający standardowe systemowe API o capabilities umożliwiające skuteczniejszy sanboxing aplikacji

Postępy DTrace we FreeBSD

Jak informuje blog Fundacji FreeBSD, zakończono projekt implementacji DTrace we FreeBSD. Ostatnim krokiem było wsparcie dla instrumentacji aplikacji.

Since DTrace on FreeBSD now has the ability to instrument both the kernel and the userland program, you can get very meaningful data on how your program is behaving and why.

DTrace to drugi po ZFS killer-feature Solarisa zaimplementowany pod FreeBSD.

Ciekawe, czy w przyszłości wyrocznia będzie równie łaskawa dla tego typu dzielenia się dobrymi rzeczami, co słoneczko.

RouteBricks

Rok po roku opensource podgryza kolejne przyczółki branży IT, okupowane dotąd przez rozwiązania komercyjne.

Są takie miejsca, w których ekspansja jest łatwa - dziś już chyba nikt nie wyobraża sobie płacenia za program do przeglądania zdjęć? Choć wiem, że niektórzy płacą np. za edytory tekstu ze wsparciem dla programowania ;) W innych przypadkach idzie nieco trudniej - choćby "ekspansja" Linuksa na desktopach... Są i takie, w których wejście na lukratywny rynek jest bardzo trudne - we wpisie z Open Source Day 2010 przytoczyłem przykład profesjonalnych baz danych.

Innym tego typu obszarem są urządzenia sieciowe. Widać postęp - od lat wiele urządzeń w segmencie SOHO (np. routery bezprzewodowe) to po prostu małe komputerki oparte np. o MIPS-a, z Linuksem w środku. Otwartość oprogramowania to tylko jeden z czynników, krytyczny jest jednak wzrost możliwości obliczeniowych architektury PC. Co by nie mówić o tym wzroście, przy wysokowydajnym przełączaniu pakietów IP, PC nie jest w stanie konkurować ze specjalizowanymi układami. Ale i tak kawałek tortu jest podgryzany, obsługa dziesiątek czy setek megabitów ruchu IP na pececie nie jest wielkim problemem. We wpisie z meetBSD 2010 pisałem o ekstremalnym rozwiązaniu pewnego bułgarskiego ISP, opartym o FreeBSD. ;) Elastyczność platformy PC w roli routera nie zawsze jest atutem, toteż powstają takie produkty jak Vyatta. Jest jednak poziom, z którym trudno się równać.


Trafiłem jednak w sieci na dający nadzieję artykuł: Software Router Smashes Speed Records. Ostateczne, jeśli procesor PC wciąż jest za słaby, można poszukać mocy w karcie graficznej. Można też zainstalować karty z układami FPGA. Oczywiście, wciąż ogranica nas magistrala. Istnieje równiez inicjatywa RouteBricks korzystająca z Clicka, gdzie wydajność routowania skaluje się... zrównoleglaniem, czyli zwiększając liczbę pecetów. Niestety, prototyp rozwiązania wciąż nie jest komercyjnie dostępny.

BSNMP

Pakiet Net-SNMP (dawniej UCD-SNMP) to bardzo popularna implementacja agenta SNMP. Dostarcza oprogramowanie użytkowe (sam agent jak i narzędzia) oraz biblioteki udostępniające API dla innych programów i języków programowania.

Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.

Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".

Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.

Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.

FreeBSD 8.1 - zmiany zwracające uwagę

W lipcu wydano FreeBSD 8.1. Wpis - suchar? Trochę tak. ;) Na liście zmian tej wersji systemu znalazłem kilka interesujących rzeczy.

Rozbudowane IPFW ("ipfw3"), czyli natywny firewall FreeBSD (pf jest importowany z OpenBSD). Pojawiła się w końcu możliwość eksportu do pseudourządzenia ipfw0 (analog do pflog0). Śledzenie pracy firewalla narzędziami typu tcpdump jest naprawdę przyjemniejsze niż syslog. Wiele algorytmów wyszukiwania zmieniło złożoność czasową na niższą. Mocno przepisany został dummynet.

Widać też postępujący proces migracji sterowników ATA pod interfejs CAM, który obejmował dotąd SCSI. Dzięki temu można będzie stosować wspólne API przy dostępie do obu rodzin urządzeń dyskowych.

Zmiany od Polaków: pojawił się HAST, ale o tym wspominałem wcześniej. Jest także wsparcie dla NFSv4 ACLs (więcej).

Enterprajsowo, pojawiła się komenda service sterująca usługami. ;)

Wreszcie pojawiło się wsparcie w skryptach startowych do hurtowego tworzenia puli VLAN-ów na danym interfejsie fizycznym, ponazywanych według konwencji znanej z ruterów, np. em0.X (VLAN X na pseudointerfejsie em0).

Gorzej, ale czasem szybciej

Natknąłem się niedawno na ciekawy, a do tego świeży (czerwiec 2010) artykuł "You're Doing It Wrong", który popełnił znany z asertywnych wypowiedzi deweloper FreeBSD i Varnisha, Poul-Henning Kamp.

Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.

Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.


Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)

meetBSD 2010 Kraków

W dniach 2-3 lipca 2010 odbyła się w Krakowie konferencja meetBSD. Wśród prelegentów dominowali goście zagraniczni, w tym deweloperzy systemu FreeBSD. Poziom merytoryczny był wysoki, ale i momentami "ciężki" gatunkowo. Może właśnie dlatego na sali wykładowej było wiele pustych miejsc? Sama sala była zresztą świetna, podobnie jak cały budynek Wydziału Matematyki i Informatyki UJ.

 

Społeczność BSD jest wyraźnie mniejsza niż Linuksowa, także ta komercyjna. Zapewne dlatego Linux wyraźnie wyprzedza FreeBSD w niektórych obszarach. Są to m.in. sieciowa replikacja urządzeń blokowych (np. DRBD) oraz możliwości wirtualizacji. Na konferencji swoje prelekcje mieli autorzy rozwiązań adresujących te luki: HAST-a (Paweł Jakub Dawidek) i VImage (Marco Zec); są one w dość wczesnej fazie rozwoju, ale mają szansę na upowszechnienie wraz z kolejnymi wydaniami linii FreeBSD 8.x.

HAST
HAST odpowiada funkcjonalnie DRBD - replikuje dyskowe urządzenia blokowe (providerów GEOM). Na ten moment implementuje tylko tryb replikacji synchronicznej i nie wspiera pracy multimaster. Według autora jest już jednak w pełni funkcjonalny.

VImage
VImage to wirtualizacja stosu sieciowego. Pamiętam jeszcze patche do FreeBSD 4.x - wówczas było to rozwiązanie zaskakująco zaawansowane, ale chyba wyprzedziło zapotrzebowanie użytkowników. ;) Obecnie VImage zintegrowane jest z oficjanym jądrem (ale nie jest domyślnie wkompilowane) i wraz z jailami stanowi odpowiednik linuksowego OpenVZ. VImage nie wspiera jeszcze pf-a, ale wspiera ipfw i IPsec. Według autora możliwe są problemy ze stabilnością - feature ma status experimental.
Uwagę zwracało graficzne narzędzie do projektowania topologii wirtualnych maszyn z magicznym przyciskiem do aplikowania zaprojektowanych zmian na systemie. Widać, że autor używa tego do symulowania różnych topologii sieciowych i zabawy z protokołami rutingu (w puli jaili, każdy z osobnym stosem sieciowym, biegały Quaggi).

High-speed traffic
Szczególnie zainteresował mnie wykład dotyczący wysokowydajnego rutowania i policowania ruchu abonenckiego na FreeBSD. Nikolay Aleksandrov prezentował rozwiązanie wydewelopowane wewnętrznie dla potrzeb jednego z bułgarskich ISP (warto sprawdzić ofertę - jesteśmy 100 lat za Bułgarami;)):

• zmodyfikowali sterownik karty sieciowej Intela, stworzyli pewien odpowiednik Netgrapha
• zrównoleglili polling na wiele rdzeni CPU i kart

i w ten sposób praktycznie pominęli stos sieciowy systemu - przy pomocy specjalizowanych "węzłów" dopasowują i przekładają ramki pomiędzy VLAN-ami i portami kilku 4-portowych kart 1Gbit, przy okazji go kolejkując. Jako że przepuszczają przez tą maszynę także ruch między abonentami, mają naprawdę duże obciążenie - jeśli dobrze zapamiętałem (slajdów jeszcze nie ma) przy kilkunastu tysiącach abonentów jest to około 2Mpps, 2Gbps ruchu Internetowego i 20Gbps wewnętrznego. To wszystko przycinanie i równoważone w około 200 tys. kolejek (jeden z ich węzłów do procesowania pakietów) na dość zwyczajnej platformie serwerowej Intela z Xeonami przy stabilnym 50% obciążeniu. Aha, zrobili hook do BPF-a (por. wpis o ringmapie), przez co możliwa jest wydajna inspekcja ruchu. Zabawne, do jak ciekawych rzeczy można doprowadzić brak pieniędzy na "profesjonalne rozwiązania". Niestety... kod nie jest na razie publicznie dostępny. ;)

Wieczorny Social Event z koncertem był bardzo przyjemny, a darmowe piwo lało się strumieniami. :P

Ringmap - wydajne przechwytywanie ruchu sieciowego na FreeBSD

Jak co roku Google uruchomiło program Summer of Code. GSoC to niezwykle wartościowa inicjatywa, katalizująca zmiany w różnych projektach open source, wykonywane rękoma pełnych zapału (i głodnych dolarów) studentów nadzorowanych przez doświadczonych mentorów. Program ten ma sens biznesowy dla Googla - pomijając kwestie wizerunkowe, polepszanie jakości ogólnodostępnego oprogramowania sprzyja tworzeniu przeciwwagi dla Microsoftu.

Jednym z wspieranych projektów jest oczywiście FreeBSD. Na liście wspartych w tym roku projektów możemy znaleźć m.in. Ringmap Capturing Stack for High Performance Packet Capturing. Projekt stara się zaadresować problemy wydajnościowe napotykane podczas przechwytywania (sniffing) ruchu sieciowego z użyciem klasycznego Berkeley Packet Filter, kojarzonego bardziej z narzędziem tcpdump (i innymi korzystającymi z biblioteki pcap).

Aplikacja korzysta z wywołań biblioteki pcap aby instrumentować jądro (BPF) do przechwytywania (w warstwie łącza danych) pakietów spełniających określone kryteria. Kryteria zadajemy wyrażeniem filtrującym, np.:

tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)

Fragmenty pakietów spełniających kryteria kopiowane są następnie z przestrzeni jądra do przestrzeni użytkownika, do aplikacji (np. sniffera wydobywającego hasła).

Ten model przetwarzana słabo skaluje się w świecie powszechnych w serwerach interfejsów sieciowych 1Gbit i coraz śmielej wkraczających 10Gbit. Szczególnie kosztowne jest kopiowanie danych (raz - wewnątrz jądra, drugi - do przestrzeni użytkownika), którego częściowo uniknięto wprowadzając we FreeBSD 8 mechanizm Zero-Copy BPF Buffers.

Ringmap ma na celu wprowadzenie prawdziwego zero-copy ;) poprzez mapowanie pamięci DMA karty sieciowej bezpośrednio do przestrzeni użytkownika. Wymaga to oczywiście szczególnego wsparcia po stronie sterownika karty sieciowej - projekt koncentruje się na 10Gbitowych Intelach (ixgbe).

Istnieją również inne pomysły na usprawnienia i rozszerzenia w podsystemie BPF: multiqueue BPF support and other BPF features. Jedno z rozszerzeń (wspomniane pod koniec prezentacji Zero-Copy BPF Buffers) to Direct-to-disk BPF - mechanizm bezpośredniego zapisu ruchu sieciowego na urządzenie dyskowe (zachodzący w całości w przestrzeni jądra). Z pewnością zafrapuje to niektórych subskrybentów POLIP-a, gdzie od czasu do czasu powraca zagadnienie logowania danych u ISP, jego zakresu i możliwości technicznych realizacji na szybkich łączach. ;) Jednym z ograniczeń jest z pewnością konieczność stosowania specjalizowanego podsystemu dyskowego - wysycone obustronnie łącze 10Gbit to przeszło 2.5GB danych na sekundę.

Poza BPF istnieją również inne, nieco mniej standardowe mechanizmy kopiowania ruchu sieciowego do przestrzeni użytkownika, zarówno we FreeBSD jak i w Linuksie. Ale o tym może... innym razem?


Zobacz także:

• bpf(4)
• tcpdump(1) 
• http://www.tcpdump.org/

unix time

Systemy uniksowe tradycyjnie reprezentują czas jako liczbę sekund, które upłynęły od czasu t0 równego 1970-01-01 00:00:00 UTC (tzw. Epoch).

Większość aplikacji formatuje znaczniki czasu do postaci strawnej dla człowieka. Czasem jednak pojawia się konieczność przeanalizowania danych bardziej niskopoziomowych, w których znajdziemy znacznik czasu w postaci surowej.

Jak szybko dokonać konwersji w jedną i drugą stronę? Choćby przy pomocy Perla. A bez Perla da się? Da się. Otóż można do tego celu użyć po prostu polecenia... date.

Implementacja date różni się między systemami. Zauważmy na przykład, że w GNU date czas sekundowy należy poprzedzić znakiem @ (nie ma tego w podręczniku ekranowym man, ale jest w info).

Konwersja czasu na format uniksowy:

freebsd$ date -j -f "%Y-%m-%d %H:%M:%S" "2010-05-07 02:34:59" "+%s"
1273192499

linux$ date -d "2010-05-07 02:34:59" +%s
1273192499

Konwersja czasu z formatu uniksowego:

freebsd$ date -j -f "%s" 1273192499
ptk 7 maj 02:34:59 2010 CEST

linux$ date -d @1273192499
pią, 7 maj 2010, 02:34:59 CEST

A gdybyśmy chcieli przetworzyć format sekundowy jako jeden z elementów wiersza podanego w potoku? Z pomocą może przyjść choćby GNU awk:

$ echo 1273192499 | gawk '{print strftime("%c", $1)}'
pią, 7 maj 2010, 02:34:59

Niestety, nie każdy system (i nie każda dystrybucja Linuksa) ma domyślnie zainstalowane GNU awk.

Na koniec warto wspomnieć o wygodnych podróżach w czasie, które umożliwia nam date na FreeBSD przy pomocy opcji -v.

Aby ustalić ostatni poniedziałek przyszłego miesiąca:

1. ustawiamy się na pierwszym dniu obecnego miesiąca
2. przeskakujemy o 2 miesiące do przodu
3. cofamy się o jeden dzień (na ostatni dzień miesiąca poprzedniego)
4. cofamy się, aż znajdziemy poniedziałek 

freebsd$ date -v1d -v+2m -v-1d -v-mon
pon 28 cze 17:06:13 2010 CEST

Więcej informacji:

• http://pl.wikipedia.org/wiki/Czas_uniksowy