$ sudo aptitude install haveged

$ cat /proc/sys/kernel/random/entropy_avail

Hovedsaklig møtte vi på to problemer: ingen flere ledige inodes, og lang venting på å liste ut alle filene, med millioner av filer lagret i én og samme katalog.

Filene ble lagret på filsystemet EXT4 i Linux, Ubuntu 14.04.1 LTS.

EXT4 har en fastsatt grense for antall filer som filsystemet kan håndtere, og denne settes under oppretting av filsystemet, så denne kunne vi ikke endre.
Videre klarer ikke EXT4 å håndtere stort mer enn ca 100k filer i én og samme katalog uten at alt går i sneglefart.

Vi måtte finne et nytt filsystem, noe som ikke hadde noen øvre grense for antall filer, med unntak av diskplass så klart.

Andre filsystemer til unnsetning

Vi måtte gjøre noen tester for å finne ut hvilket filsystem vi kan bruke istedenfor EXT4.
Kandidatene vi kom fram til var BTRFS, XFS og ZFS.

I tillegg vurderte vi OneFS, et produkt fra Isilon som vi allerede har kjørende i produksjon, et nettverkslagringssystem som er spesialisert til å håndtere veldig store datamengder, men dette produktet er heller ikke bra til å håndtere veldig mange filer i én katalog.
Vi kan rett og slett ikke bruke den på grunn av risiko for å krasje hele filsystemet og ta med oss alle andre systemer i produksjon som bruker dette.

Testingen jeg gjorde er relativt enkel:

1. Opprettet tomme filer på 20 GB, loopback-montert og formattert med filsystemet som skulle testes
2. Kopierte 1.6M (1.644.553) filer på til sammen 19 GB, alle i én katalog, til hver av filsystemene
3. Tømte Linux OS-cache før testing av hvert filsystem
4. Tok tiden for detailjert sortert utlisting (kald test)
5. Tok tiden for detailjert sortert utlisting enda en gang (varm test)
6. Tok tiden for usortert utlisting (varm test)

I tillegg tok jeg noen notater om komprimeringsgrad for de filsystemene som støttet komprimering, og hvor mye OS-cache og minne som ble brukt etter gjennomført testing.
Maskinene har noen bakgrunnsprosesser som vil kunne allokerer noe minne mens testene kjøres, men jeg anses aktiviteten på disse som lite i forhold til ressursbeslaget disse testene vil gjøre.

Hastighet på lesing eller skriving av innholdet i filene er ikke det viktigste for oss.
Det er små filer, fra 50 KB til 500 KB, så det er viktigere at vi kan lese flere filer raskt enn å lese én stor fil raskt.

Vi trenger et filsystem som lar oss jobbe med filene, skrive nye filer, flytte filer og kopiere filer når behovene melder seg, istedenfor å krype stille sammen for å dø – altså er uthenting av metadata om filer og utlisting av filene viktige kriterier.

For å tømme OS-cache på Linux kjørte jeg følgende kommando:

echo 3 | sudo tee /proc/sys/vm/drop_caches

For utføring av testen “detailjert sortert utlisting” kjørte jeg følgende kommando:

time ls -lht KATALOG | wc -l

For utføring av testen “usortert utlisting” kjørte jeg følgende kommando:

time ls -1 -U KATALOG | wc -l

Disse kommandoene tar tiden for å liste ut filer.
I steden for å bruke tid på å printe ut all teksten til konsollet så gjorde jeg en telling av linjer, som også ble en verifikasjon på at jeg hadde kopiert over alle filene til alle filsystemene som ble testet.

Testoppsett

Filene lå opprinnelig på Server1 på et EXT4-filsystem.
Disse ble kopiert over til Server2 hvor testene av de andre filsystemene ble gjort.
Server2 hadde omtrent ingen annen aktivitet mens testene pågikk, så målingene skal være nokså nøyaktige.
For å måle opp mot problemet vårt ble også testene gjennomført på Server1 mot EXT4.
I tillegg gjennomførte jeg en test på Server1 over NFS mot XFS-filområdet til Server2.

Filsystemene ble i hovedsak opprettet med standard-opsjoner på Ubuntu 14.04.1 LTS.
Komprimering ble aktivert i BTRFS og ZFS.

Resultater

På Server1 gjennomførte jeg en tømming av OS-cache, men målte ikke minneallokeringsbruk, da det er andre tjenster som kjører på serveren, og det kunne gitt villedende resultater.

NFS-testen fra Server1 mot Server2 sitt XFS-testoppsett mangler noen måletall, tall jeg anså som uviktige å måle på grunn av nettverksseparasjonen.
Den kalde testen av detaljert utlisting av filer ble ikke gjennomført over NFS.

Skriving av filer til ZFS ble merkbart tregere for hver fil som ble skrevet – i starten var overføringshastigheten over 6.5 MB/s, men slutta på 3.2 MB/s.
Usikkert om det skyldes komprimering, diskstørrelse eller andre årsaker.

Tid ble målt i minutter og sekunder.
BTRFS, XFS og ZFS allokerer inodes dynamisk.

EXT4 var eneste som hadde et maksimalt antall inodes.
BTRFS rapporterte ikke om inodes i “df -i”, verken ledige eller brukte.
Både XFS og ZFS var fleksible i ledige inodes som ble rapportert og endret seg i takt med ledig diskplass.

Alle filsystemene gjennomførte testene innen akseptabel hastighet når systemet var varm.
Allikevel var BTRFS og XFS de raskeste her med svar på under 20 sekunder, mens ZFS brukte 33 sekunder og EXT4 brukte 44 sekunder.

XFS var klart raskest når systemet var kald med svar på under 2 minutter.
EXT4 og BTRFS var nokså like med omkring 3,5 minutter når systemet var kald.
ZFS brukte uakseptabel lang tid (over 8 minutter) når systemet var kald.

EXT4, BTRFS og XFS leverte et akseptabelt raskt svar på usortert utlisting av filene, på maksimalt 2 sekunder.
XFS var raskest, på 1 sekund.
ZFS brukte uakseptable 15 sekunder.

Alle filsystemene unntatt EXT4 allokerte mye minne og cache for å utføre testene.
Det er usikkert om loopback-monteringen på Server2 kan ha hatt innvirkning.
EXT4 allokerte bare 109 MB som cache, men den var også noe tregere enn de andre når systemet var varm.
XFS allokerte 3.5 GB minne, hvorav 830 MB cache.
ZFS allokerte 3.3 GB minne, hvorav 1.4 GB cache.
BTRFS allokerte 5.9 GB minne, hvorav 3.7 GB cache.

Konklusjon

Vi anså XFS til å være best for våre behov.
Den leverte svar innen akseptabel tid både da systemet var kaldt og varmt, og var også den raskeste til å levere usortert utlisting av filene.

ZFS skuffet stort med uakseptabelt trege svar.
BTRFS brukte for mye minne, men ellers virket den lovende.

Felles for både BTRFS og ZFS var at komprimering var aktivert.
Kanskje kunne minnebruken vært lavere for både BTRFS og ZFS om testingen ble utført uten komprimering.

Det er god aktivitet rundt BTRFS i Linux-kildekoden og ser ut til å bli arvtakeren til EXT3/4.
BTRFS har funksjoner for blant annet komprimering og snapshotting, og det vil være aktuelt med ny vurdering av BTRFS senere.

Avslutning-rant

Etter at ny diskenhet ble koblet til Server1 og XFS ble satt opp, så dukket et nytt problem fram – overføring av filene fra EXT4-partisjonen til den nye XFS-partisjonen gikk i trege 1 MB/s.
Løsningen ble å overføre filene tilbake fra Server2 sitt XFS-filsystem over NFS…

Et enda større problem møtte vi med en annen katalog, som inneholder omkring 1.1 millioner kataloger, som igjen inneholder filer, men mer om dette kan diskuteres over et par kanner kaffe – jeg har god tid…

Det jeg derimot glemte å skrive var hvordan man skulle koble opp mot den for å sende kommandoer, noe jeg så klart har glemt siden den gang og trøblet litt med i kveld.

Det jeg sleit mest med er at alle terminalklientene jeg testet har aktiv maskinvarebasert flytkontroll, noe som ikke fungerer mot denne receiveren. Så det må skrus av.

Dette kan gjøres via minicom eller kermit. Beskrivelse finnes blant annet hos Gumstix Developer Center.

Etter at flow control er skrudd av kan minicom kjøres:

minicom -b 9600 -D /dev/ttyUSB0 -8 -o

Et tips hvis du bruker minicom er å aktivere “Add linefeed” i konfigurasjonen av “Screen and keyboard”.

At night this tool makes the screen a bit warmer, so your eyes wont “hurt” so much of the otherwise so bright display of your desktop background, browser or editor.

You provide the tool with your approximately geo coordinates and some value for upper and lower limit of color temperature, then it will automatically and continuously change color temperature all through day and night.

Example command for running this tool, if your’re in Norway:

$ redshift -l 60.0:10.0 -t 5700:3600 -g 0.8 -m vidmode -v

Since then I have had varying success capturing hours of video from both Hi8 and VHS sources. Often lavrec will exit in the middle of a recording with somewhat unknown error messages such as:

# dmesg:
DC10plus[0]: jpg_sync - timeout: codec isr=0x00

# lavrec:
Error syncing on a buffer: Timer expired

… and other nicies.

Often this happened between recordings on the tape, when stopping and starting a recording, where it often occur a lot of noise and jitter. It happened more often when recording from VHS tapes than from HI8 tapes.

I tried different values for the system configuration kernel.sched_time_avg with what looks like random improvements. The default is 1000 on a normal Ubuntu Desktop 10.10. I have tried both 100 and 250, and 250 is what I am currently using. Change it like this:

$ sudo sysctl kernel.sched_time_avg=250

I was previously using KDE while recording, but found out that several background processes like Akonadi Server was running and stealing resources. The window manager seemed slow. I guess I have an I/O issue somewhere, but I just don’t know where. Maybe the SCSI drive or maybe the graphics card which is an old ATI Radeon 8500.

I an now running Openbox with Konsole, as a command line (in an X server) is all I need to both record and watch the result with mplayer afterwards. I feel it goes a little bit smoother.

The most effect, as I figured out, was setting the quality option of lavrec a little lower. Recording with the quality set to 100 might result in unstable recording with lost frames if there is the slightest delay in the system, and eventually lavrec just exits with an error.

I tried setting the quality to 80, just to give it a try, and it was recording much more smoothly with less dropped frames. It looks like lavrec now handles jitter much better.

I am now trying out a quality of 90 which also seems good. A little lost frames now and then, but I guess that occurs mostly between recordings since I am able to record several minutes from a single scene without a single frame drop.

This is the command I use now:

$ aoss lavrec --mjpeg-buffers 512 --mjpeg-buffer-size 8192 -f q -d 1 -i p -q 90 -s -R l -U "dc10-%02d.mov"

So, my best tip to avoid lost frames and lavrec crashes is to lower the quality a little.

First, the camcorders charger is broken, and buying a new one is kind of difficult, but luckily, I got to borrow one from some friends.
Second, I managed to find the last working VHS player I got. A little dusty.
Third, since Mini-DV is kind of legacy as well, I decided to copy those on to my computer as well, if I ever manage to find the camcorder. Got the charger, remote and the casing, but no camcorder. Oh well…

Find the best composite or S-Video cables you can dig up, because this job you only want to do once. I got my overly priced Monster composite cables, ready to start. Soon…

Ok, so I’ve got an analog video capture card that I, in the old days, used with Windows 98 and pulled my hair out to get working on Windows 2000. The card is a Zoran based Pinnacle/Miro DC10+. That’s history. Sort of. I still got the video capture card.

What I also got is the latest Ubuntu Linux 10.10, also known as Ubuntu Maverick, which comes with the somewhat great ALSA audio support. I say somewhat because this version of Ubuntu lacks the legacy OSS compability driver in the Linux kernel. In other words it makes it harder to record or play audio from older kinds of programs, such as lavrec.

lavrec is the video and audio capture application from the MJPEG video tools package. It is the tool recommended for capturing video from the DC10+ card on Linux, but it lacks ALSA support. However, you can get a OSS wrapper program named aoss from the Ubuntu alsa-oss package which provides OSS is most cases for those old applications.

This is how I do video and audio recording, from the command line, enter something like this:

$ aoss lavrec -f a -i p -q 100 -s -R l -U dc10-out.avi

Make sure that the correct recording input line is selected for CAPTURE in alsamixer -V capture such as Line or Mic. I recommend you capture a 10 second test and check the sound.

Jeg hadde nettopp behov for å sette opp et utvikler driftsmiljø for en PHP-applikasjon jeg skriver. Jeg ønsket ikke å sette den opp på arbeidsstasjonen min da jeg ikke ønsker å male meg opp i et hjørne dersom denne skal byttes ut eller oppgraderes. Det å sette opp et driftsmiljø er noe kjedelig dersom det må gjøres for ofte. Bestemte meg derfor å teste ut KVM.

KVM og QEMU er noenlunde like, på en måte, hvorav KVM er maskinvareakselerert virtualisering. QEMU støtter virtualisering av flere plattformer, dersom man har behov det.

Etter et par søk på Google fant jeg fram til artikkelen Using Linux KVM Virtualization on Ubuntu Gutsy Gibbon 7.10 som beskriver veldig enkelt en del kommandoer man kan kjøre.

Jeg lastet ned nyeste Ubuntu. Først forsøkte jeg amd64-versjonen, men denne fungerte ikke da jeg tydeligvis kjørte i686-versjon av Ubuntu på vertsmaskinen. Selv om CPU-en støtter 64bit så er det OS-et som må støtte 64 bit dersom du ønsker å kjøre 64-bit gjeste-OS i KVM. Så jeg endte opp med å laste ned i386-versjonen av Ubuntu Lucid.

$ qemu-img create lucid-server.img -f qcow2 10G
$ kvm -no-acpi -m 750 -cdrom $HOME/ubuntu-10.04.1-server-i386.iso -boot d  -k no -vnc :2 lucid-server.img

Legg merke til opsjonen “-vnc :2″ som gjør at KVM setter opp en VNC-server på port 5902. Dette gjorde jeg fordi jeg ikke ønsker at vinduet med den virtuelle serveren skal vises på vertsmaskinen, men jeg vil allikevel ha muligheten til å se skjermbildet. Dette er strengt tatt også nødvendig for å installere Ubuntu.

PS: Sånn helt på tampen… boota nettopp Ubuntu 10.04 i KVM på en 3 år gammel maskin… vips var loginskjermen der – rask!

OPPDATERING:
For å sette opp bridge-nettverk slik at den virtuelle maskinen kan motta IP-adresse fra DHCP, så må du konfigurere et bridge-grensesnitt på vertsmaskinen. På Ubuntu gjør du det ved å legge til følgende i /etc/network/interfaces:

auto br0
iface br0 inet dhcp
    bridge_ports    eth0
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0

Du må reloade nettverksinnstillingene:

/etc/init.d/networking restart


Til kvm-kommandoen for å starte den virtuelle maskinen legger du til følgende opsjoner:

-net nic,vlan=0 -net tap,vlan=0,ifname=tun0

Illustrasjonsfoto: Canon Compact Flash Card av Simon Clayson, Creative Commons

Jeg ga Linux-maskinen min et forsøk. Ved første øyekast så det mørkt ut og jeg fikk mange stygge feilmeldinger i dmesg-loggen. “fdisk -l” viste meg ingen partisjoner på minnekortet.

Jeg prøvde å ta ut og sette inn kortet igjen, bare for å sjekke en gang til. Denne gangen gikk det mye bedre.

Først tok jeg en kopi av minnekortet til en fil med verktøyet dd. Dette er viktig å gjøre hvis man har med ustabilt medium å gjøre for å ikke slite unødvendig på minnekortet eller risikere å slette noe.

$ sudo dd if=/dev/sdb of=/tmp/sdb.dd

Deretter lastet jeg ned programmet TestDisk fra CGSecurity. Dette er et gjenopprettingsverktøy som jeg ikke har brukt tidligere. Det dukket opp i flere søkeresultater på Google, så jeg ga det en sjanse. Og jeg kommer garantert til å bruke det ved liknende anledninger senere.

Jeg startet testdisk med “/list”-opsjonen mot kopien jeg lagde av minnekortet, for å se om verktøyet fant noe nyttig om disken.

$ sudo testdisk /list sdb.dd
TestDisk 6.10, Data Recovery Utility, July 2008
Christophe GRENIER 

http://www.cgsecurity.org

Please wait...
Disk sdb.dd - 256 MB / 245 MiB - CHS 32 255 63, sector size=512

Disk sdb.dd - 256 MB / 245 MiB - CHS 32 255 63
    Partition                  Start        End    Size in sectors

Partition sector doesn't have the endmark 0xAA55

Dette lovet ikke bra. Jeg forsøkte så å starte opp testdisk uten list-opsjonen og ble så presentert med en meny for å velge disk søke etter partisjoner, samt noen valg.

Jeg forsøkte flere av valgene, blant annet at disken var opprettet på et i386-system, men da fant den ingen partisjoner. Siden dette minnekortet har stått i et kompaktkamera var det sikkert ikke opprettet noen partisjoner på kortet, så jeg forsøkte det valget i stedet.

Det viste seg at det ikke var noen partisjoner på kortet. Filsystemet, som var vfat, var skrevet rett på minnekortet. Programmet viste meg en filbrowser og jeg kunne navigere rundt og kopiere ut filer.

Det ga meg også mulighet til å kopiere ut filer som tidligere hadde vært slettet. Jeg forsøkte å hente ut to bilder, for å teste dette. Det ene bildet var korrupt, trolig skrevet over etter at det var slettet, mens det andre bildet kunne vises uten problemer.

Må si at dette verktøyet var en stor suksess!

Debian Lenny
Debian kom for en stund siden i ny stabil versjon, “Etch”, og siden jeg fortsetter å holde meg på testing-versjonen så var det på tide å oppgradere til neste versjon, som er “Lenny”. Det gikk litt sakte å navigere rundt i Freevo fordi maskinen har så lite minne, og oppstart av Enlightment som var installert på boksen gikk slimete tregt. Målet er å kunne bruke PC-en til noe nyttig igjen.

Videoredigering
Tidligere har jeg brukt en Athlon 1800+ til videoredigering, men redigering av HD-video tar mye ressurser, og jeg frykter at denne blir for treg. Jeg har en relativt kraftig maskin som stue-PC i leiligheten min som nå bare kjører MythTV. Denne har dual-core prosessor Athlon 5600+, og denne ønsker jeg å bruke til litt videoredigering. Det er derimot ikke optimalt å bruke TV-en som skjerm når jeg skal redigere. TV-en er bare “HD-ready” med en oppløsning på 1280×720, som blir noe snaut. Jeg har en 22″ widescreen LCD-skjerm som da egner seg bedre, men denne står i et annet rom og egner seg ikke for stua av opplagte grunner (ja, den tar jo litt plass). I tillegg frister det ikke så mye å koble om på kablene bak på stue-PC-en.

Dermed blir kanskje løsningen tynnklient-teknologi. En relativt dårlig PC (les: 733 MHz) kobler seg på X-serveren på en relativt kraftig PC (les: stue-PC), og signaler fra mus og tastatur blir sendt til X-serveren og skjermbildet blir sendt tilbake. For å få noe fornuftig opp på skjermen bruker man XDMCP, som støttes av innloggingstjenester som KDM, GDM og XDM. Jeg utførte en enkel test med å koble 733MHz-boksen opp mot laptopen, som vi fra nå av kaller henholdsvis tynnklient og tykklient.

XDMCP
Som sagt er XDMCP en protokoll for å koble på X-sesjoner, enten på lokal PC eller på andre PC-er i et nettverk. Det vi ønsker å oppnå er å koble oss på en innloggingstjeneste på tykklienten og få skjermbildet opp på tynnklienten. Til det skal vi bruke SSH med X-videresending, Xnest som er en X-sesjon som kan kjøres i et vindu i en annen X-sesjon og KDM som innloggingstjeneste.

Først måtte det gjøres noen konfigurasjonsendringer i KDM, som er den innloggingstjenesten jeg benytter på laptopen, som er en del av KDE-prosjektet. I konfigurasjonfilen /etc/kde3/kdm/kdmrc endret jeg på seksjonen Xdmcp for å aktivere tjenesten. Her vises et lite utdrag fra konfigurasjonfilen:

[Xdmcp]
Enable=true

Deretter måtte jeg endre i filen /etc/kde3/kdm/Xaccess for å fortelle kdm hvilke maskiner som får lov til å benygge innloggingstjenesten. Dette gjøres ganske enkelt ved å la kun ordet “localhost” stå skrevet i denne fila. For å tillate alle adresser på nettverket tilgang til tjenesten skriver du en stjerne, “*”. Grunnen til at jeg kun oppfører localhost kommer vi videre inn på snart.

Oppkobling
På tynnklienten startet jeg opp en enkel X-sesjon og terminalprogrammet xterm. Så logget jeg inn på tykklienten med ssh med kommandoen:

ssh -X tykklient

Opsjonen -X betyr videresending av X-applikasjoner som gjør at alle grafiske applikasjoner jeg starter i SSH-sesjonen blir vist i X-sesjonen til tynnklienten. Dette vil for mange være akkurat det de trenger dersom de har en egen window manager (som KDE eller Gnome) på PC-en sin.

Dette er ikke nok for meg. Jeg vil ha mer. Jeg skriver så inn følgende kommando:

Xnest :1 -geometry 1024×768 -query localhost

Opsjonen -geometry setter jeg til samme størrelse som min lokale X-sesjon. Dette kan du sjekke med kommandoen “xdpyinfo”, og se etter noen de første linjene som printes av dette programmet. Opsjonen -query henviser til tykklienten, fordi vi er inne i SSH-sesjonen på denne maskinen. Her ser du grunnen til hvorfor vi førte opp kun localhost i Xaccess-konfigurasjonsfilen over.

Dette oppsettet gir oss tre fordeler. For det første åpner vi ikke tjenesten for ukjente maskiner på nettverket, for den andre at alle tynnklientbrukere må ha gyldig konto på tykklienten for å logge på med SSH og for det tredje vil all trafikk bli kryptert over SSH-forbindelsen. I tillegg vil en brannmur kunne gi enda bedre sikring på punkt én.

Da var det bare å logge inn og fyre opp kdenlive, videoredigeringsprogrammet jeg bruker og har blitt så glad i. Avspilling av videokilder i kdenlive gikk bra, så da er 733MHz-boksen klar til å bli shippet over til leiligheten.

Påsken er over
Da er påsken over for i år. Jeg vet jeg lovet å undersøke mer omkring søkemotoren Solr, men det ble det ikke tid til. Jeg har så vidt touchet temaet søkemotorer og synes det er et spennende tema. Mulighetene er også tilstede for å ta i bruk Solr eller andre søkemotorer i kommende prosjekter på jobben i nær fremtid.

Jeg gikk derfor til anskaffelse av en nettverksdisk, også kalt NAS, for å lagre musikken på for at jeg enkelt skal kunne ta med musikken dit jeg vil uten å måtte ta med den store serveren min, som blant annet også fungerer som web- og mailserver. D-Link NAS-323 virket som et godt valg, både billig, har gigabit nettverkskort og har mulighet for å holde to harddisker. Jeg valgte en løsning med to ganger 500 GB harddisker for å få en TB med lagringsplass, som kommer til nytte når man har mye musikk og ønsker et sentralt område for deling av filer.

Jeg satte i diskene, noe som var gjort på under ett minutt, startet den opp, gikk til webgrensesnittet og satte opp diskene i RAID-0 for “økt ytelse” og for å utnytte kapasiteten fra diskene mest mulig. Harddisker ryker når man minst ønsker det, men jeg satser på å synkronisere musikkfilene mellom filserveren min og DNS-323 såpass ofte at det ikke er verdens undergang dersom en av harddiskene skulle ryke.

Ytelsen på diskene var lavere enn forventet med omtrentlig 24 Mbit per sekund. Dette var ikke under optimale nettverksforhold, da jeg har en router som ruter trafikken mellom subnettene. Jeg har betraktelig raskere hastighet på overføring mellom laptopen og filserveren, så det var noe skuffende filserveren ikke klarte å overføre filene raskere til nettverksdisken enn dette her. Laptopen står på samme subnett som nettverksdisken.

Figuren til venstre viser overføring fra laptopen i mellomrommet fra kl 20 til 21 og til nettverksdisken i mellomrommet fra kl 22 til 24. Sammenlikningen blir ikke helt korrekt, da ytelsestesten mot nettverksdisken ble utført over Samba, mens overføringen fra laptopen ble utført over NFS. Jeg skal undersøke hastigheten på lesing fra nettverksdisken når overføringen som nå pågår er ferdig, og da skal jeg teste overføring både over Samba og FTP.

Nettverksdisken støtter FTP og Samba for overføring av filer, i tillegg til å være uPNP AV-tjener og iTunes-tjener. I bunnen ligger GPL/Linux og kildekoden er tilgjengelig fra D-Link sine nettsider. Den har også innebygget printer server for tilkobling til printere med USB-grensesnitt.

Det finnes en uoffesiell nettside for DNS-323 med mye informasjon om maskinvaren og hvor det ligger tilpasset programvare og informasjon for å installere tilleggsprogrammer som NFS-tjener og rsync. Nettverksdisken har en 500 MHz ARM prosessor, 64 MB ram og kjører Linux 2.6.12.6.