RSS Atom Add a new post titled:

If you are an intermediate or advanced user of ZFS, then this post is probably not for you.

Introduction

I only recently started looking seriously at ZFS. So far general skepticism about "new stuff" taking care of my precious files, has kept ZFS from being used by me.

But no more. I am going to convert my home server to ZFS, when I get home from The Camp. This post will document some of the decisions and solutions I arrived at while at The Camp.

My requirements for storage are:

  • Full disk encryption
  • Resilience for single drive failures
  • Rock solid filesystem

So far these have been met by gmirror + GBDE + ufs2. But the possibility of having my filesystems share a pool of free space, have had me thinking about ZFS for some time. It would be nice not to have to move stuff around when one filesystem runs out of space.

I was a little worried about how disk failures would manifest themselves, and how they should be handled in order not to loose data. Thus I brought 3 USB disks to The Camp - one with known bad blocks.

Sven Esbjerg held a great ZFS workshop at The Camp, which I attended. It provided a nice crash course in ZFS. During the workshop, I played with setting up two disks as a mirror. When the one with bad blocks gave errors when adding data to the mirror, I could play with replacing it with the spare disk. All worked as expected.

While my requirements included full disk encryption, I also wanted raidz in order to gain more usable disk space.

Looking around I found this convoluted way of doing it, but I wanted to keep it (more) simple - even at the cost of not giving ZFS direct control of the disks. This blog post gave me a nice starting point.

In the end I opted for encrypting the devices with geli, and adding ZFS on top of that.

Configuring ZFS and testing failure

This is done on a laptop, using USB drives, called /dev/daN. Devices on a server would be something like /dev/adaN or /dev/adN.

I will create 3 encrypted devices, tell ZFS to use them, and create a pool spanning them all.

# Create encrypted devices
geli init -s 4096 /dev/da0      # Using a blocksize of 4096 to be prepared
geli init -s 4096 /dev/da1      #   for future disks that use 4K blocks
geli init -s 4096 /dev/da2      # da2 is the bad disk
# Attach the devices for use
geli attach /dev/da0
geli attach /dev/da1
geli attach /dev/da2
# Create the zpool (called "tank"), spanning all 3 devices
zpool create tank raidz1 /dev/da0.eli /dev/da1.eli /dev/da2.eli

I then started to fill-up the pool in order to trigger errors from the bad disk.

for i in `jot 10` ; do dd if=/dev/zero bs=1m count=10240 of=/tank/zero1.$i; done
for i in `jot 10` ; do dd if=/dev/zero bs=1m count=10240 of=/tank/zero2.$i; done
# ... etc ...

When the bad blocks were used, errors started to be logged in /var/log/messages, but nothing was registering in ZFS.

From /var/log/messages:
# ...
Jul 25 22:03:39 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): WRITE(10). CDB: 2a 0 c d0 64 20 0 0 80 0 
Jul 25 22:03:39 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error
Jul 25 22:03:39 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): Retrying command
Jul 25 22:04:53 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): WRITE(10). CDB: 2a 0 c d0 64 20 0 0 80 0 
Jul 25 22:04:53 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error
Jul 25 22:04:53 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): Retrying command
Jul 25 22:06:06 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): WRITE(10). CDB: 2a 0 c d0 64 20 0 0 80 0 
Jul 25 22:06:06 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error
Jul 25 22:06:06 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): Retrying command
Jul 25 22:07:20 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): WRITE(10). CDB: 2a 0 c d0 64 20 0 0 80 0 
Jul 25 22:07:20 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error
Jul 25 22:07:20 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): Retrying command
Jul 25 22:08:34 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): WRITE(10). CDB: 2a 0 c d0 64 20 0 0 80 0 
Jul 25 22:08:34 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): CAM status: CCB request completed with an error
Jul 25 22:08:34 <kern.crit> guide kernel: (da2:umass-sim2:2:0:0): Error 5, Retries exhausted
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110071791616, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110071922688, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072053760, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072184832, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072315904, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072446976, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072578048, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110072709120, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110071529472, length=131072)]
Jul 25 22:08:34 <kern.crit> guide kernel: GEOM_ELI: Crypto WRITE request failed (error=5). da2.eli[WRITE(offset=110071660544, length=131072)]
# ...

This kept going for a couple of hours (I kept adding data), while ZFS claimed that all was fine. Finally ZFS saw enough errors, and dropped the bad disk (i forgot to save the output of 'zpool status' here).

I detached the disk from the USB port, and ZFS shows:

guide ~ 90# zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has been removed by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: scrub in progress since Wed Jul 25 22:45:40 2012
        188G scanned out of 312G at 38.7M/s, 0h54m to go
        0 repaired, 60.17% done
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      DEGRADED     0     0     0
          raidz1-0                DEGRADED     0     0     0
            da0.eli               ONLINE       0     0     0
            da1.eli               ONLINE       0     0     0
            17292134696089706765  REMOVED      0     0     0  was /dev/da2.eli

I have lost a disk, but raidz allows for that, while still allowing access to all data.

Getting access to the pool after reboot

After reboot, the state is:

guide ~ 1# zpool status
  pool: tank
 state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
    replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
   see: http://illumos.org/msg/ZFS-8000-3C
  scan: none requested
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      UNAVAIL      0     0     0
          raidz1-0                UNAVAIL      0     0     0
            7434867841503891175   UNAVAIL      0     0     0  was /dev/da0.eli
            2223752624539388409   UNAVAIL      0     0     0  was /dev/da1.eli
            17292134696089706765  UNAVAIL      0     0     0  was /dev/da2.eli

Without having attached the geli devices, ZFS cannot find its data, and the pool is offline.

Attach the devices for use:

guide ~ 3# geli attach /dev/da0
Enter passphrase:
guide ~ 4# geli attach /dev/da1
Enter passphrase:

ZFS now finds the devices, but does not mount the data sets.

guide ~ 5# zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has been removed by the administrator.
  Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: scrub repaired 0 in 1h58m with 0 errors on Thu Jul 26 00:43:43 2012
config:

        NAME                      STATE     READ WRITE CKSUM
        tank                      DEGRADED     0     0     0
          raidz1-0                DEGRADED     0     0     0
            da0.eli               ONLINE       0     0     0
            da1.eli               ONLINE       0     0     0
            17292134696089706765  REMOVED      0     0     0  was /dev/da2.eli

Mount the datasets.

guide ~ 8# zfs mount -a

My data are ready to be used again.

If this was not just a test setup, I would get a new drive and add it to the pool.

geli init -s 4096 /dev/da2      # Assuming that da2 was the new drive
geli attach /dev/da2
zpool replace tank 17292134696089706765 /dev/da2.eli

ZFS would now resilver the pool, and after a while the new drive would have all the needed data copied to it, and the pool would again have enough redundancy to allow for the loss of one drive.

Keeping an eye on ZFS

In order to get reminders about the state of ZFS in the nightly emails, I have added ZFS status to /etc/periodic.conf. Furthermore, I have asked the system to run scrub on the pool every 8 days.

guide ~ 22# cat /etc/periodic.conf 
daily_status_zfs_enable="YES"
daily_status_zfs_zpool_list_enable="YES"
daily_scrub_zfs_enable="YES"
daily_scrub_zfs_default_threshold=8

Had this been my server, I would now have a good feeling about being informed about the state of my filesystems.

Further thoughts

It is my experience from these tests, that ZFS does not like it when drives belonging to a pool disappear, not even when all filesystems in that pool has been unmounted. Thus I would not recommend using USB drives as removable storage with ZFS for production use.

When replacing a failed drive in a raidz (or a mirror), the new drive should be the same size or larger than the smallest drive at creation of the pool. This should surprise no one.

In practice large drives will differ slightly in size (unless they have the same partnumber). It is therefore prudent to not use the full drive, but leave, say, 100MB-1GB unused at the end. That way it is certain that the new 2TB drive - that you managed to get after hours - will not be 20 sectors too small.

With this in mind, my creation above would have been something like:

guide ~ 2> fgrep sectors: /var/log/messages
Jul 26 18:13:45 <kern.crit> guide kernel: da1: 953869MB (1953525167 512 byte sectors: 255H 63S/T 121601C)
# ...   # This time my phone was da0

guide ~ 1# gpart destroy -F da1
guide ~ 2# gpart create -s GPT da1
guide ~ 3# gpart add -b 2048 -s 1953000000 -t freebsd-zfs da1       # (1953525167-1953000000)/2/1024 = 256MB free
                                                                    # Start at block 2048 means ready for 4K drives
guide ~ 5# gpart show da1
=>        34  1953525100  da1  GPT  (931G)
      34        2014       - free -  (1M)
    2048  1953000000    1  freebsd-zfs  (931G)
  1953002048      523086       - free -  (255M)
# Repeat for da2 and da3

guide ~ 10# geli init -s 4096 /dev/da1p1                            # Note the use of "p1"
# Repeat for da2 and da3

guide ~ 15# geli attach /dev/da1p1
# Repeat for da2 and da3

guide ~ 20# zpool create tank raidz1 /dev/da1p1.eli /dev/da2p1.eli /dev/da3p1.eli

And we are now ready with .5G space less in tank (256M less at 3 drives, of which 1/3 would have been used for redundancy).

Conclusion

I feel that this way of adding crypto to ZFS is the best way, at least until the day Oracle decides to opensource the changes from v28 to v33. It does encrypt the data plus the redundancy, but I see no real alternative to this, if I want the extra benefits of ZFS.

Posted Fri Jul 27 11:40:03 2012 Tags:

Jeg fandt dette opslag på min gadedør, da jeg kom hjem fra arbejde idag.

IMAGE
(Klik for større version)

Jeg skal ikke gøre mig klog på baggrunden for situationen.
Bare konstatere at nogen gange går det galt for vores vigtige data.

Og så er godt at have en backup.
Vi, der arbejder professionelt med IT, er sjældent i tvivl om at det er en god ide at have en grundig backup strategi. En del af os har endda implementeret noget backup for vores private data.

For vores venner og bekendte, der bruger computere som et nødvendigt redskab, så er det ikke altid indlysende at man bør sikre sig. Og derved kommer de indimellem i klemme, som M. i ovenstående opslag.

Backup strategi

En god strategi ved projektarbejde er at have en USB stick med 7 underkataloger - et for hver ugedag. Hver aften, når man er færdig med dagens arbejde, kopieres alle de projekt relevante filer til dagens katalog.

USB sticken skal derefter placeres et sted der er uafhængigt af computeren, og hvor evt. tyve ikke vil finde den. Hvis både laptop og USB stick mistes samtidig, så er backupen jo intet værd.

Menneskelige fejl i editering og deciderede fejl i den anvendte software kan ødelægge teksten man skriver på. Dette kan oftest reddes ved at gå tilbage til en af de 7 kopier man har tilbage i tiden.

Om man også vil beskytte sig mod brand, eller om man synes at, hvis ens hjem er brændt af, så er projektet det mindste problem, må man tage stilling til.
Hvis man vil beskytte sig mod brand, så bør man have yderligere to USB sticks. Den ene har man hjemme og hver gang det er belejligt, så kopierer man alle projekt relaterede filer til den, og bytter den med den man har liggende uden for hjemmet (på arbejde, på skolen, hos en ven, ...). På denne måde roteres de to USB sticks så ofte man kan.

En anden god strategi er at sende alle filerne til sin egen gmail konto hver aften.
Så ligger data på googles servere, og er altid til at få fat på.

Vejled venner og bekendte om backup

Ovenstående er næppe særligt nyt eller overraskende for læserne af denne blog.
Men for mange af jeres venner er det måske - så det er op til jer at sikre, at de ikke ender som M. her.

Brug evt. dette opslag som en øjenåbner for de, der ikke umiddelbart kan se pointen i at tage backup.

Posted Mon Jun 6 22:03:15 2011 Tags:

This blog has been quiet for a long time.
This is mostly due to me being busy, and not having much to write about.

Also, some of the reason is that Anton, who hosted my blog from the start in late 2008, announced that he was going to abandon the old Movable Type blog platform in favor of ikiwiki.
Not feeling much inclined to use time on a doomed platform, I did not write.

Back in January, Anton helped me migrate my stuff to ikiwiki, and all that that was left was some css hacking. However Open Source Days 2011 was right around the corner, and the new blog project was put on hold.

But now it is finished, and my new ikiwiki powered blog is live.

During the process, I discovered that ikiwiki is very easy to host, thus I moved the blog to my own server. Thanks much to Anton for the hosting of the old blog, and all the resulting Movable Type hacking and patching.
I can only recommend that you look into ikiwiki, just as Anton writes here.

I have tried to keep old links working, but stuff is bound to be forgotten ...
Comment here to have it fixed.

Posted Wed Mar 30 15:37:15 2011 Tags:

Today I got this mail from Amazon.

Greetings from Amazon.co.uk,

As someone who has purchased or rated "Toy Story 2 (2 Disc Collector's Edition) [1999] [DVD]" or other titles in the Regular Stores > Audio Description category, you might like to know that "It's Complicated [Blu-ray] [2009]" is now available. You can order yours for just £15.71 (37% off the RRP) by following the link below.

It's Complicated [Blu-ray] [2009]
Meryl Streep

I mean, really, how is a Meryl Streep movie in any way comparable to Toy Story 2?
And what is it with this Regular Stores > Audio Description category?

Please try harder.

Posted Sun May 30 17:21:43 2010 Tags:

Det er altid en underlig tom fornemmelse at vågne søndag morgen efter Open Source Days.

Flere måneders målrettet indsats er kulmineret. Og festen er nu vel overstået.
Pludselig er der ikke en mulliard opgaver der skal huskes, og en zillion ting der skal koordineres med 'de andre'[1].

Morgenen (dvs. formiddagen/middagen) er foregået halvt i zombie tilstand.
Det lokale brunch sted havde lukket, så jeg har holdt den gående på bagerbrød og Red Bull.
Jeg er helt klart blevet for gammel til at tage 4 pre-konference dage og 2 16 timers konferencedage (incl. en pæn del efter-konference-øl) uden men.

Jeg stod som de foregående år for at sikre at der var net og strøm til udstillere og brugergrupper.
Til at hjælpe med dette havde jeg igen iår et super Net-crew, bestående af:
Lars Thegler, Jenny Hadfield, Henrik Andersen, Jesper Frilund, Michel "Yuki" Inoue, Jon Erichsen, Asbjørn Thegler & Søren Schrøder [2]
Tak gutter, det var igen iår en fornøjelse at arbejde sammen med jer.
(Det skal kraftigt understreges at vi ikke havde noget med det trådløse net at gøre. Det er 100% konfigureret og administreret af IT-U.)

Også tak til alle vores konference hjælpere. Det er jeres fortjeneste at alt det praktiske under konferencen har forløbet så glat som det gjorde. I er alt for mange til at nævne her, men i ved hvem i er.

Det er min opfattelse, at alt på konferencen forløb uden reelle problemer.
Jeg havde derfor tid til at se flere af foredragene. Og de jeg var nødt til at misse håber jeg at DKUUGs video team fik båndet. Hold øje med websiden for at se når de er online.

Tilbage er nu at få klaret de løse administrative ender, hvor den vigtigste er at sikre at vi får aflagt regnskab til vores ejere, DKUUG. Uden DKUUGs velvillige økomnomiske backing havde der ikke været nogen Open Source Days konference.

På det mere personlige plan er det pludselig gået op for mig, at vasketøjskurven har fået rekord top på, og at de steder min Roomba ikke kan nå, har et decideret gråt og let uldent skær i forårssolen. Papirene i TODO bunken på skrivebordet ser ud til at være i akut fare for at komme i skred og planterne ser temmeligt indtørrede ud. Afgjort en god plan også at tage en fridag mandag.

spacer.png

[1] Hanne, Kristian, Peter og Sidsel
[2] Sorteret efter 2. bogstav i fornavn. Hvorfor ikke?

Posted Sun Mar 7 15:00:46 2010 Tags:

Billedet herunder viser IT-universitetet i forårssolen.

Det er her Open Source Days 2010 løber af stabelen fredag og lørdag.

Open Source Days[1] er for mig en af de vigtige events, der bebuder forårets komme. Og arbejdet med at få konferencen op at stå, har altid hjulpet med at få de kedelige og triste vintermåneder til at gå hurtigere.

Nu er der kun de sidste hektiske 1½ dage tilbage til festen begynder.

Kommer du?

img_4308.jpg

spacer.png

[1] inklusive de tidligere konferencer under LinuxForum navnet.

Posted Wed Mar 3 16:21:27 2010 Tags:

Anders and I were doing our usual after-lunch-walk, when we passed this sight.

towing.jpg

It is not as bad as some of the pictures found on the net, but still funny.

Posted Sun Feb 21 15:44:46 2010 Tags:

While driving with my friend Anders, we passed this truck.
Luckily the highway was busy, and i could make him slow down a little, and get in behind it for pictures.

it-rental.jpg

My apoligies for the shaky picture. It is the best of the 30 odd pictures I took. I blame Anders car and his driving skills :-)
The text is "www.@it-rental.dk".

According to whois, the it-rental.dk domain does not exist anymore. I wonder why ...

Update:
Peter Larsen has spotted that the domain is lt-rental.dk, which seems to be very much alive.

Posted Sun Feb 21 15:09:14 2010 Tags:

Tilbage i december, lige før jul, bestilte jeg en HD og noget RAM hos SHG.

Jeg får altid mine pakker sendt til den lokale døgnpost, idet jeg så kan hente dem, når det passer min kalender, istedet for når det passer post.dk at holde åbent. Jeg var blandt de første kunder på systemet, og det har generelt fungeret godt.
Jeg har hver gang fået en mail med 2 pinkoder, og disse har jeg så indtastet på døgnposten, og fået min pakke udleveret.

Jeg fulgte ivrigt min pakke på Track&Trace, men den så ud til at være fanget i systemet med status "23/12 - Ankommet til 704 Københavns Pakkecenter".
Så 2/1 ringede jeg til kundeservice, og spurgte til min pakke, og de mente at afsenderen skulle melde den bortkommet.
Jeg sendte derfor en mail til SHG, hvor jeg bad dem sende mig en ny, siden nogen tilsyneladende havde hugget min pakke, nu hvor den stadig var markeret som liggende på pakkecenteret.
I forbindelse med skriveriet med SHGs support slog jeg d. 7/1 pakken op på Track&Trace. Og nu var min pakke pludselig ankommet til døgnposten d. 23/12, og var returneret 4/1.
Altsammen uden at jeg havde modtaget nogen form for besked fra post.dk.

Da jeg så 7/1 fik en mail om at SHG havde afsendt min DVB-T tuner, og jeg idag 9/1 stadig ikke havde modtaget nogen mail med pinkode til afhentning, men Track&Trace viste at pakken lå i døgnposten, begyndte jeg at kigge på problemet.

Jeg greppede i min mail log, og fandt følgende:

Jan 8 10:18:51 <mail.notice> fj sendmail[86279]: o089IpR1086279: ruleset=check_mail, arg1=<jboss@dp-adbprod1>, relay=mailgw2.post.dk [193.3.69.5], reject=553 5.1.8 <jboss@dp-adbprod1>... Domain of sender address jboss@dp-adbprod1 does not exist

Og det er jo klar snak. Post.dk kan ikke finde ud af at sætte en korrekt afsender på deres mails.
Og det er formentlig også grunden til at jeg aldrig modtog en mail om min julepakke.

Jeg ville egentlig gerne have min pakke her til weekenden, så jeg tænkte at jeg bare ville bede om at få pinkoderne til døgnposten gensendt til min mobil telefon. Jeg loggede ind på post.dk, og lagde mit mobilnummer ind.
Desværre kan man ikke få gensendt pinkoder i post.dk's system, så jeg var tvunget til at ringe til deres kundeservice.

Hos kundeservice snakkede jeg med en flink og serviceminded ung mand, som forklarede at de havde store problemer med at deres mails ikke blev modtaget hos kunderne, og han tilbød mig at få pinkoderne over telefonen. Jeg fik mine pinkoder, og kvitterede med at forklare ham hvorfor deres mails blev væk, og hvad han skulle slå udviklingsafdelingen oven i hovedet med. Han lød noget forundret, men ville give beskeden videre.
Jeg håber at de meget snart fixer problemet - men jeg beholder nu mit mobilnummer i systemet, bare for lige at være sikker ...

Tilbage er spørgsmålet så, hvorfor post.dk ikke tester deres nye systemer?
Hvordan kan en så grel fejl få lov til at eksistere i produktion i så lang tid?
Alle moderne mailservere nægter jo at modtage mails fra en afsender, hvis domæne ikke kan slås op.
Hvis man har lavet den mindste smule overvågning af det nye system, så ville man have set 90+% af alle mails blive afvist med en fejlmelding, lignende den min mailserver har leveret tilbage.
Især når man er nået til den konklusion at mails ikke når frem, så ville det da være indlysende at debugge lokalt som det første - det er jo her man har skiftet system, og det er her man har de bedste muligheder.

Men nej, det var altså en kunde, der skulle gøre arbejdet.

Og jeg har stadig ikke fået min HD og min RAM. Jeg håber at SHG snart gensender.
Og min DVB-T tuner ligger stadig i døgnposten, for fyren i kundeservice fortalte mig at han lige havde fejlmeldt min døgnpost, med at brugerinterfacet var frosset/crashet ...

Suk!

Posted Sat Jan 9 13:12:36 2010 Tags:

Min arbejdsplads ligger i sydhavnen.

Politiet transporterer de forskellige COP15 ping'er mellem Bella og City via Sydhavnsgade - dvs. samme route man brugte da man gennemførte den latterlige ide at fragte Obama til Christiansborg, istedet for at fragte Christiansborg politikerne til Bella Centeret.

Under Obama-i-København hysteriet fandt politiet at det var nødvendigt, at forbyde folk at benytte de parkeringspladser der lå indenfor ca. 30m af Sydhavnsgade (bilbomber er så ubehagelige - bare spørg de stakkels mennesker i Irak).
Man havde ydermere haft folk og bombehunde ved/i alle brønde i vejen på routen, og derefter "forseglet" dem.
Og op til transporterne af Obama, blev alle biler, der ikke respekterede parkeringsforbudet, bare fjernet. Man havde en hel flåde af kranvogne til at hænge ud på den nærliggende tankstation, og de ventede bare på at få noget at lave.
Alt i alt et rimeligt afbalanceret valg af forholdsregler, givet trusselsbilledet i forbindelse med Obamas besøg. Men jeg gætter også på, at de havde PET og Secret Service til at hjælpe. Både med sikkerhedsvurderingen og med at sikre at der blev indført forholdsregler, der dækkede truslerne i en grad, der sikrede at det rette sikkerhedsniveau også blev nået i praksis.

Mine kollegaer, der til hverdag pendler i bil, var naturligvis ikke begejstrede over i praksis at miste halvdelen af P-pladserne i området, men jeg fornemmede at de fleste godt kunne se det fornuftige i politiets handlemåde. Og ydermere havde politiet annonceret det i god tid, så alle kunne nå at indrette sig.

Nu under COP15 var der så tilsyneladende en eller anden halvstuderet papirskubber i etaten, der hentede planen frem igen som basis for de forholdsregler, der skulle tages denne gang.
Planen bliver læst igennem, budgettet studeres, og det konstateres at de to ting tydeligvis ikke hænger sammen. Man begynder derefter at klippe i planen, hvorved kontrol af brønde forsvinder, idet det er dyrt og mandskabskrævende (og det kan jo heller ikke ses af de besøgende at her er sparet), helikopter eskorte af konvojerne ser jo flot ud, omend det er lidt dyrt, så det beholdes (det er jo ret tydeligt for de besøgende med sådan en helikopter over hovedet), blokering af P-pladser er jo reelt gratis (og de besøgende der er lidt observante vil måske bemærke det), fjernelse af biler der overtræder parkeringsforbudet er jo dyrt med alle de kranvogn-timer, så det forsvinder (og det bemærkes næppe gennem de tonede ruder).

Vi ender altså med at der igen indføres parkerings forbud, mens ingen af de andre forholdsregler mod bomber gennemføres.
Dette forbud annonceres lige inden fyraften mandag, og gælder så ikke kun een dag som under Obama besøget, nej, det gælder tirsdag til fredag.
Med andre ord, mine stakkels bil-pendlende kollegaer har reelt intet varsel for en meget væsentlig indgriben i deres arbejdsdag.

Og det nytter jo ingenting. Fordi de biler, der allerede var parkeret, blev ikke fjernet. De biler, der ignorerede forbudet, bliver ikke fjernet. Man har opnået chikanen af de almindelige borgere, og absolut ingen af de fordele der kunne have været.

Dette bringer mig til titlen på dette rant.
Nogle i nabobygningen fik åbenbart nok, og besluttede sig for, i den for tiden så populære 'civil ulydighed'-stil, at ignorere idiotien.
img_4011.blur.jpg

De parkerede biler er kørt hen over de opsatte rød-hvide politi afspærrings bånd i morges.
Betjenten, der ses på billedet, har lige fixet afspærringen og sat nyt bånd op bag bilerne.
Meget passivt aggressivt

Som det ses herunder, er det tydeligt kun eet firma, hvor man er civilt ulydige. img_4014.jpg

Og billede taget den modsatte vej. img_4013.jpg

Bemærk bilen der stikker ud ved det blå skilt. Den er ikke ved at køre, den kunne ikke komme længere ind på den stopfulde parkeringsplads.

Jeg håber egentlig, at der er flere i sydhavnen, der imorgen viser de voldelige venstreekstremister hvad fredelig civil ulydighed helt præcist er.
For i dette tilfælde kan jeg kun støtte bilisterne i deres 'Fuck Politiet' holdning.
Politiets holdning til den almindelige borgers tid, fortjener ganske enkelt ingen respekt.

Som sikkerhedsprofessionel kan jeg kun grine (eller måske endda græde) over en politietat, der åbenlyst ikke er istand til at implementere en sammenhængende plan, mod et trusselsbillede der er gennemanalyseret tidligere.

De vælger istedet hovedløst at plukke i forholdsreglerne, tydeligvis ud fra hvad der ser godt ud, og hvad der er gratis for etaten. Dette gøres uden at anerkende at tiltag, der generer borgerne, reelt også har en pris.
Hvor det rigtige havde været at se hvad budgettet rakte til af sikkerhedsniveau, og så implementere efter det - og dermed nå et reelt niveau uden ressourcespild. Så ender man her med sikkerhed der når et (forhåbentligt korrekt) niveau, med ekstra klasket på, der er helt uden værdi i praksis, men som har en høj pris.

Ynkeligt!

Posted Thu Dec 17 19:54:15 2009 Tags:

This blog is powered by ikiwiki.