Bilişim dünyası ile yakından ilgilenenlerin bileceği üzere, önümüzde bizi bekleyen önemli bir konu var: 2038 yılı problemi!
Üstelik bu defa 2000 yılındaki gibi yüzyıl değişimi ve konunun gereğinden fazla medyada yer bulup abartılmasından kaynaklanan yapay bir problem değil, gayet sahici ve ciddiye almamız gereken bir senaryo ile karşı karşıyayız.
Bu yazımızda konuyu hem genel hatlarıyla hem de Linux çekirdeği ve sistem çağrıları özelinde incelemeye çalışacağız.
Neden 2038?
Aslında tam tarih verecek olursak, 19 Ocak 2038 UTC saat 03:14:07'den bir sonraki saniyede problemle karşılaşmış olacağız.
Bunun temel nedeni, UNIX sistemlerde zaman bilgisini saklamak için kullanılan time_t veri tipinin 32 bitlik işaretli bir tamsayı olmasıdır. Unix epoch time olarak da adlandırılan bu yöntemde 0 değeri 1 Ocak 1970, 00:00:00 UTC tarihini ifade eder. Saniye bazında ilerleyen bu sistemde 32 bitin negatif ve pozitif yöndeki sınırlarına kadar gittiğimizde 13 Aralık 1901 ve 19 Ocak 2038 tarihlerine ulaşırız.
Epoch time bilişim jargonunda bir dönemin sonu yeni bir dönemin başlangıcı anlamında kullanılagelmiştir. Unix epoch time için 1970'in seçilmiş olması da bu yüzdendir. Bununla birlikte NTP, ZigBee, FAT32, Apple Cocoa vb. epoch time kullanımları da bulunmaktadır. Ayrıntılı bilgiye wikipedia üzerinden erişebilirsiniz.
64 bit'lik sistemlerde sorun çözülmüş olmuyor mu?
Sorunun sadece bir kısmı çözülmüş oluyor. Maalesef problemi tüm sistemlerde çözebilmenin sihirli bir formülü bulunmuyor.
64 bitlik bir işlemci kullanmak, işletim sistemi çekirdeği, sistem çağrıları arayüzü ve kullanılan C kitaplığı (glibc vb.) özelinde zamanla ilgili sorunun büyük oranda çözülmesini sağlıyor. Ancak merkezden çevreye doğru ilerlediğimizde problemin pek çok noktada tekrar karşımıza çıkacağını göreceğiz. Hızlıca bir kaç problemli alanı listeyecek olursak:
Dosya sistemleri: pek çok dosya sisteminde zaman bilgileri 32 bit olarak saklanmaktadır
Çeşitli binary formatları: bir çok binary formatında header veya data kısmında zaman bilgileri için 32 bitlik alanlar kullanılır
Veritabanları: bir çok veritabanı 32 bitlik zaman bilgisi saklamak için veri tipleri içermektedir
Network protokolleri: bazı network protokollerinde de zaman bilgisi için 32 bit ayrılmış durumdadır
Yukarıdakilere ek olarak bir kaç kişinin kullandığı küçük yardımcı uygulamalardan geniş kullanıcı kitlelerine ulaşmış paket programlara kadar sayısını bilemeyeceğimiz adette irili ufaklı yazılımda da benzeri sorunlar yaşanacağını hesaba katmamız gerekir ki asıl can yakıcı sorunlar muhtemelen buralarda ortaya çıkacaktır.
Daha 23 yıl var, dert etmeye değer mi?
Önümüzde uzun sayılabilecek bir zaman olduğu doğru. Sözgelimi ben de o tarihte yaşıyorsam 58 yaşında olacağım, dolayısıyla problemle asıl uğraşmak zorunda kalacak olanlar şu an ya emekle aşamasındalar ya da henüz doğmadılar bile..
Bununla birlikte probleme önceden hazırlıklı olma adına sistemlerde yapılması gerekenleri elbette değerlendirmemiz, üzerinde kafa yormamız gerekiyor. Sadece işletim sistemi çekirdeği ve sistem çağrıları arayüzü noktasından bakmaya başlamamız da yeterli olmayacaktır zira eğer şu an önümüzdeki 25 yıl boyunca çalışması beklenen bir yazılım tasarım sürecinin içerisinde iseniz bu durumun farkındalığı ile ilerlemeniz daha iyi olacaktır.
Linux çekirdeğinde yapılan hazırlıklar
Linux çekirdeğinde 2038 yılı problemine ilişkin, öncesi ve sonrası hazırlıkları çoktan başlamış durumda. Çekirdeğin kendi içinde zamanı hangi veri tipi ile tuttuğu o kadar önemli bir problem değil zira değişiklik yapıldığı anda kendi içinde tutarlı olarak yeni haliyle çalışmaya başlayacaktır.
Çekirdek tarafında konuyla ilgili asıl önemli nokta, çekirdeğin dış dünya ile arasındaki temel iletişim katmanı olan sistem çağrıları arayüzünden zamanla ilgili sistem çağrılarını sunacağı arayüzde ne gibi değişiklikler yapılması gerektiğidir.
Çekirdek tarafında dikkate değer ilk yaklaşım Thomas Gleixner'den geldi. Thomas'ın önerisi çekirdek içerisinde zaman verisinin tek bir şekilde, ktime_t yapısı ile 64 bit ve nanosaniye hassasiyetinde tutulması şeklindeydi. Böylelikle zamanın saniye kısmı için ayrı bir alan kullanılmayacak, daha basit bir gerçekleştirimle ilerlenecekti.
Ancak bu yaklaşım hem kullanıcı kipi geçişlerinde daha fazla dönüşüm operasyonu gerektiriyor hem de tutulan zaman verisinin saniye kısmı için ayrı bir alan kullanılmadığından ötürü, toplamda adreslenebilecek zaman aralığı artmakla birlikte halen yaklaşık olarak 585 yıl ile sınırlı kalmasına yol açıyordu.
Şu an kabul gören yaklaşım ise struct timespec veriyapısının 64 bitlik struct timespec64 şeklinde yeni bir versiyonunun üretilmesi şeklindedir. Kullanıcı kipinden baktığımızda gettimeofday() gibi struct timeval ile çalışan fonksiyonlar kullanıcı kipinde iken dönüşüme tabi tutularak çekirdeğe geçmeden önce clock_gettime sistem çağrısına dönüştürülecektir. 32 bitlik sistemler çekirdek ile zaman bilgisi veri alış verişlerinde struct timespec64 kullanmaya başladıklarında (glibc gibi C kitaplıkları üzerinden dolaylı olarak gerçekleşecektir) problemin çekirdek - kullanıcı kipi haberleşmesine bakan kısmı çözülmüş olacaktır.
32 bitlik yazılımlar ne olacak?
Çekirdeğin tamamında zaman verileriyle ilgili 64 bit geçişi yapıldığında -ki bu yakın gelecekte olacak, 2038 beklenmeyecek- mevcut binary'lerin çalışmaya devam etmesi gibi bir sorunumuz da bulunuyor. Örneğin 32 bitlik sisteminize Debian Jessie dağıtımını kurdunuz ve sonra zaman veri işlemelerinde 64 bit kullanan yeni bir çekirdek derlediniz diyelim. Eski yazılımların çalışmaya devam etmesini nasıl sağlayacağız?
Bu sorunun çözümü için CONFIG_COMPAT_TIME adında yeni bir çekirdek opsiyonu bulunuyor olacak. Eğer 32 bitlik bir X86 veya ARM işlemciniz varsa bu özelliği seçmeniz halinde sistem çağrılarının 32 bitlik zaman verisi bekleyen compatibility modunda (uyumluluk) çalışan eski versiyonları da çekirdek içerisinde yer alacak. Örneğin 32 bitlik X86 sistemlerdeki 265 numaralı clock_gettime sistem çağrısı uyumluluk desteği aktif bir çekirdekte çağırdığınızda, compat_sys_clock_gettime adında yeni bir fonksiyonla karşılanacak ve zaman verisi kullanıcı kipine 32 bit olarak iletilecektir.
Elbette bu şekildeki uyumluluk modu ile 32 bitlik uygulamaları çalıştırma işlevi ancak 2038 yılına kadar mümkün olacaktır. 2038 sonrası için bu uygulamaların mutlaka yeni C kitaplıklarını kullanacak şekilde yeniden derlenmesi ve uygulama içerisinde de zaman verileriyle ilgili olası diğer yansımalarının çözümlenmesi gerekecektir.
Çekirdek tarafında çözüm bekleyen diğer noktalar
Zamanla ilgili sistem çağrılarında nasıl bir yol izleneceği netleşmiş olmakla birlikte, time_t veri tipiyle işlem yapan bazı ioctl() çağrılarının da kod içerisinde tek tek bulunup dönüştürülmesi gerekmektedir. Bu süreç de bir miktar zaman alacaktır.
Dosya sistemleri tarafından baktığımızda örnek olarak Ext4 dosya sisteminde dosyalarla ilgili zaman verileri inode yapılarında 32 bit uzunluğunda saklanmaktadır. 2038 yılı problemine ilişkin Ext4'de zaman verilerine 2 bit daha eklemek suretiyle 34 bit olarak saklama imkanı üzerinde durulmaktadır (bkz: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps). Bu modelde 2446 yılına kadar zaman bilgisini saklamak mümkündür.
XFS dosya sistemine baktığımızda orada halihazırda padding amaçlı kullanılmayan bir 6 byte olduğundan daha şanslıyız. Ext4 gibi sadece 2 bit eklemek yerine, dosyaların erişim, değiştirme, meta-data güncelleme ve ilk oluşturma tarihlerini tutan 4 alana birer byte eklemek suretiyle, şu anki duruma göre fazladan 255 epoch zaman aralığı elde etmiş olacağız ve bu da bizleri 19 binli yıllara kadar idare edecektir. Eminim şu an yüreğinize su serpilmiş gibi rahatladınız!
Benzer problemler hemen her dosya sistemi için bulunduğundan her birinde ayrı çözümler gerekecektir.
Bitirirken..
Yazı fazla uzamaya başladığından son söz olarak, resmin bütününe baktığımızda epey sancılı bir sürecin bizleri beklediğini, özellikle de uygulamalar üzerindeki problemin dolaylı yansımalarının başımızı ağrıtacağını tarihe not düşerek bitirelim.
2038 yılı problemine hazır mıyız!
Bilişim dünyası ile yakından ilgilenenlerin bileceği üzere, önümüzde bizi bekleyen önemli bir konu var: 2038 yılı problemi!
Üstelik bu defa 2000 yılındaki gibi yüzyıl değişimi ve konunun gereğinden fazla medyada yer bulup abartılmasından kaynaklanan yapay bir problem değil, gayet sahici ve ciddiye almamız gereken bir senaryo ile karşı karşıyayız.
Bu yazımızda konuyu hem genel hatlarıyla hem de Linux çekirdeği ve sistem çağrıları özelinde incelemeye çalışacağız.
Neden 2038?
Aslında tam tarih verecek olursak, 19 Ocak 2038 UTC saat 03:14:07'den bir sonraki saniyede problemle karşılaşmış olacağız.
Bunun temel nedeni, UNIX sistemlerde zaman bilgisini saklamak için kullanılan time_t veri tipinin 32 bitlik işaretli bir tamsayı olmasıdır. Unix epoch time olarak da adlandırılan bu yöntemde 0 değeri 1 Ocak 1970, 00:00:00 UTC tarihini ifade eder. Saniye bazında ilerleyen bu sistemde 32 bitin negatif ve pozitif yöndeki sınırlarına kadar gittiğimizde 13 Aralık 1901 ve 19 Ocak 2038 tarihlerine ulaşırız.
64 bit'lik sistemlerde sorun çözülmüş olmuyor mu?
Sorunun sadece bir kısmı çözülmüş oluyor. Maalesef problemi tüm sistemlerde çözebilmenin sihirli bir formülü bulunmuyor.
64 bitlik bir işlemci kullanmak, işletim sistemi çekirdeği, sistem çağrıları arayüzü ve kullanılan C kitaplığı (glibc vb.) özelinde zamanla ilgili sorunun büyük oranda çözülmesini sağlıyor. Ancak merkezden çevreye doğru ilerlediğimizde problemin pek çok noktada tekrar karşımıza çıkacağını göreceğiz. Hızlıca bir kaç problemli alanı listeyecek olursak:
Yukarıdakilere ek olarak bir kaç kişinin kullandığı küçük yardımcı uygulamalardan geniş kullanıcı kitlelerine ulaşmış paket programlara kadar sayısını bilemeyeceğimiz adette irili ufaklı yazılımda da benzeri sorunlar yaşanacağını hesaba katmamız gerekir ki asıl can yakıcı sorunlar muhtemelen buralarda ortaya çıkacaktır.
Daha 23 yıl var, dert etmeye değer mi?
Önümüzde uzun sayılabilecek bir zaman olduğu doğru. Sözgelimi ben de o tarihte yaşıyorsam 58 yaşında olacağım, dolayısıyla problemle asıl uğraşmak zorunda kalacak olanlar şu an ya emekle aşamasındalar ya da henüz doğmadılar bile..
Bununla birlikte probleme önceden hazırlıklı olma adına sistemlerde yapılması gerekenleri elbette değerlendirmemiz, üzerinde kafa yormamız gerekiyor. Sadece işletim sistemi çekirdeği ve sistem çağrıları arayüzü noktasından bakmaya başlamamız da yeterli olmayacaktır zira eğer şu an önümüzdeki 25 yıl boyunca çalışması beklenen bir yazılım tasarım sürecinin içerisinde iseniz bu durumun farkındalığı ile ilerlemeniz daha iyi olacaktır.
Linux çekirdeğinde yapılan hazırlıklar
Linux çekirdeğinde 2038 yılı problemine ilişkin, öncesi ve sonrası hazırlıkları çoktan başlamış durumda. Çekirdeğin kendi içinde zamanı hangi veri tipi ile tuttuğu o kadar önemli bir problem değil zira değişiklik yapıldığı anda kendi içinde tutarlı olarak yeni haliyle çalışmaya başlayacaktır.
Çekirdek tarafında konuyla ilgili asıl önemli nokta, çekirdeğin dış dünya ile arasındaki temel iletişim katmanı olan sistem çağrıları arayüzünden zamanla ilgili sistem çağrılarını sunacağı arayüzde ne gibi değişiklikler yapılması gerektiğidir.
Çekirdek tarafında dikkate değer ilk yaklaşım Thomas Gleixner'den geldi. Thomas'ın önerisi çekirdek içerisinde zaman verisinin tek bir şekilde, ktime_t yapısı ile 64 bit ve nanosaniye hassasiyetinde tutulması şeklindeydi. Böylelikle zamanın saniye kısmı için ayrı bir alan kullanılmayacak, daha basit bir gerçekleştirimle ilerlenecekti.
Ancak bu yaklaşım hem kullanıcı kipi geçişlerinde daha fazla dönüşüm operasyonu gerektiriyor hem de tutulan zaman verisinin saniye kısmı için ayrı bir alan kullanılmadığından ötürü, toplamda adreslenebilecek zaman aralığı artmakla birlikte halen yaklaşık olarak 585 yıl ile sınırlı kalmasına yol açıyordu.
Şu an kabul gören yaklaşım ise
struct timespecveriyapısının 64 bitlikstruct timespec64şeklinde yeni bir versiyonunun üretilmesi şeklindedir. Kullanıcı kipinden baktığımızdagettimeofday()gibistruct timevalile çalışan fonksiyonlar kullanıcı kipinde iken dönüşüme tabi tutularak çekirdeğe geçmeden önce clock_gettime sistem çağrısına dönüştürülecektir. 32 bitlik sistemler çekirdek ile zaman bilgisi veri alış verişlerinde struct timespec64 kullanmaya başladıklarında (glibc gibi C kitaplıkları üzerinden dolaylı olarak gerçekleşecektir) problemin çekirdek - kullanıcı kipi haberleşmesine bakan kısmı çözülmüş olacaktır.32 bitlik yazılımlar ne olacak?
Çekirdeğin tamamında zaman verileriyle ilgili 64 bit geçişi yapıldığında -ki bu yakın gelecekte olacak, 2038 beklenmeyecek- mevcut binary'lerin çalışmaya devam etmesi gibi bir sorunumuz da bulunuyor. Örneğin 32 bitlik sisteminize Debian Jessie dağıtımını kurdunuz ve sonra zaman veri işlemelerinde 64 bit kullanan yeni bir çekirdek derlediniz diyelim. Eski yazılımların çalışmaya devam etmesini nasıl sağlayacağız?
Bu sorunun çözümü için
CONFIG_COMPAT_TIMEadında yeni bir çekirdek opsiyonu bulunuyor olacak. Eğer 32 bitlik bir X86 veya ARM işlemciniz varsa bu özelliği seçmeniz halinde sistem çağrılarının 32 bitlik zaman verisi bekleyen compatibility modunda (uyumluluk) çalışan eski versiyonları da çekirdek içerisinde yer alacak. Örneğin 32 bitlik X86 sistemlerdeki 265 numaralıclock_gettimesistem çağrısı uyumluluk desteği aktif bir çekirdekte çağırdığınızda,compat_sys_clock_gettimeadında yeni bir fonksiyonla karşılanacak ve zaman verisi kullanıcı kipine 32 bit olarak iletilecektir.Elbette bu şekildeki uyumluluk modu ile 32 bitlik uygulamaları çalıştırma işlevi ancak 2038 yılına kadar mümkün olacaktır. 2038 sonrası için bu uygulamaların mutlaka yeni C kitaplıklarını kullanacak şekilde yeniden derlenmesi ve uygulama içerisinde de zaman verileriyle ilgili olası diğer yansımalarının çözümlenmesi gerekecektir.
Çekirdek tarafında çözüm bekleyen diğer noktalar
Zamanla ilgili sistem çağrılarında nasıl bir yol izleneceği netleşmiş olmakla birlikte, time_t veri tipiyle işlem yapan bazı
ioctl()çağrılarının da kod içerisinde tek tek bulunup dönüştürülmesi gerekmektedir. Bu süreç de bir miktar zaman alacaktır.Dosya sistemleri tarafından baktığımızda örnek olarak Ext4 dosya sisteminde dosyalarla ilgili zaman verileri inode yapılarında 32 bit uzunluğunda saklanmaktadır. 2038 yılı problemine ilişkin Ext4'de zaman verilerine 2 bit daha eklemek suretiyle 34 bit olarak saklama imkanı üzerinde durulmaktadır (bkz: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps). Bu modelde 2446 yılına kadar zaman bilgisini saklamak mümkündür.
XFS dosya sistemine baktığımızda orada halihazırda padding amaçlı kullanılmayan bir 6 byte olduğundan daha şanslıyız. Ext4 gibi sadece 2 bit eklemek yerine, dosyaların erişim, değiştirme, meta-data güncelleme ve ilk oluşturma tarihlerini tutan 4 alana birer byte eklemek suretiyle, şu anki duruma göre fazladan 255 epoch zaman aralığı elde etmiş olacağız ve bu da bizleri 19 binli yıllara kadar idare edecektir. Eminim şu an yüreğinize su serpilmiş gibi rahatladınız!
Benzer problemler hemen her dosya sistemi için bulunduğundan her birinde ayrı çözümler gerekecektir.
Bitirirken..
Yazı fazla uzamaya başladığından son söz olarak, resmin bütününe baktığımızda epey sancılı bir sürecin bizleri beklediğini, özellikle de uygulamalar üzerindeki problemin dolaylı yansımalarının başımızı ağrıtacağını tarihe not düşerek bitirelim.