Void and Null

Снощи нямах какво да правя, та взех и преведох текст от разни места и го събрах в едно материалче което разглежда принципа на действие на HFSC. Има примери как се прави това в Linux и *BSD.

Статията може да е скучна за доста хора, така че който го интересува да чете навътре

(more…)

Пускате си да гледате филмче, завивате се на топло, гасите си лампите… идилия Само че филма свършва, mplayer приключва и десктопа ви с всичките си милион и триста хиляди светещи пиксела се забива под клепачите ви. Сега трябва да ставате от топлото легло, да се разхождате до PC-то и да гасите монитора. За мързеливите има следния трик:

mplayer <опции>; xset dmps force off

След приключване на процеса на mplayer се изпълнява и втората команда, която управлява Power managment на монитора ви (standby, suspend, on, off) го изключва.

Внезапно закъсах за място на линукския дял и проведеното разследване показа, че имам 300МВ *неща* в /var/spool/clientmqueue Дълги са по около килобайт и са толкова много че rm не иска да ги трие

 # rm * /bin/rm: Argument list too long. 
# ls |wc -l 92562 

Ето какво представлява едно от тези *неща*:

 cat dfm2C0t6aE007318

array(6) { [0]=> string(52) "? (192.168.0.3) at 00:C0:95:EC:B7:93 [ether] on eth0"

[1]=> string(55) "? (85.187.229.129) at 00:30:48:8C:21:7A [ether] on eth1"

[2]=> string(55) "? (85.187.229.200) at 00:1B:24:16:B3:2B [ether] on eth1"

[3]=> string(55) "? (85.187.229.242) at 00:19:E0:0C:02:47 [ether] on eth1"

[4]=> string(55) "? (85.187.229.183) at 00:13:8F:EA:CB:F3 [ether] on eth1"

[5]=> string(0) ""

} 

Помня че едно време си играх с arpwatch и той имаше някаква опция да праща отчети при смяна на MAC адрес по пощата, ама това не си е отчет ами просто някакъв дъмп от print_r() функцията в PHP. Шаш Изтриха се де:

 
# rm *0 
# rm *1 
# rm *2 
..... 

Сега да открия какво е оставило такива спомени там

Това го има на няколко места в нета, но на всичките по нещо куцаше, така че реших да напиша как стана при мен.
1) В ядрото трябва да имате:
CONFIG_UFS_FS (Filesystems -> Miscellanious -> UFS filesystem support) - можете да го сложите като модул, но ако искате по-късно автоматично монтиране от fstab, ще трябва да го вкарате в ядрото. Ако го сложите като модул, във fstab ще опишете файловата система с noauto (иначе mount протестира че няма такава файлова система ufs - поне при мен не си зарежда автоматично модула) и в rc.local си добавете “modprobe ufs”
CONFIG_BSD_DISKLABEL (Filesystems -> Partition types -> Advanced partition selection -> PC BIOS -> BSD disklabel) - това няма опция за компилиране на модул - само директно в ядрото

2) Ако ядрото ви е наред, време е да откриете точно кое устройство ви носи UFS файловата система.

<br />
dmesg | grep bsd<br />

Ще се види нещо като:

<br />
 sdb1: &lt;bsd: sdb6 sdb7 &gt;<br />

Тук Linux вижда 1 устройство - sdb1, но FreBSD си има по-особена организация на файловите системи. Вероятно сте запознати с това, така че ще ви го спестя. Да видим как са разпознати от boot процеса на Linux - sdb6 и sdb7.
Едното ми е swap дяла, а другото root на файловата система. Ако се съмнявам кое кое е, ще пробвам по отделно:

3) Монтиране с mount:
- изберете типа на UFS - при съвременните BSD-та (или поне на FreeBSD7) е ufs2

<br />
# mount -r -t ufs -o ufstype=ufs2 /dev/sdb6 /mnt/bsd/<br />
# ls /mnt/bsd<br />
COPYRIGHT  boot   compat  dist     etc   lib      media  proc    root  sys  usr<br />
bin        cdrom  dev     entropy  home  libexec  mnt    rescue  sbin  tmp  var<br />

Уцелих от първия път

4) Описване в /etc/fstab

<br />
/dev/sdb6       /mnt/bsd        ufs     ro,ufstype=ufs2    0       0<br />

По желание можете да сложите
noauto - ако сте компилирали ufs support на модул вместо директно в ядрото
users - за монтиране от обикновени потребители без root привилегии

Всеки мрази проблеми. От всякакво естество. А най-отвратително е когато проблема уж се реши, а се оказва че само е отложен/разсеян/заобиколен/подтиснат…
Проблема е че LAN картата на случайни интервали от време спира да работи и единствения начин да се пусне е рестарт на машината. В dmesg имам:

<br />
NETDEV WATCHDOG: eth0: transmit timed out<br />

LAN картата е Realtek 8139. Текуща версия на ядрото - 2.6.25.6, но проблема съществува във всички 2.6.х
В нета са изписани хиляди мнения по въпроса - никой не може да каже точно какво е. Навсякъде се повтаря ‘грешка в драйвъра на картата’. На места пишат че от 2.6.24 нагоре проблема е оправен - да, ама не. На места пишат че Windows записвал някакви шитни в паметта на картата, които пречат на други операционни системи да активират картата. Глупости, защото във FreeBSD нямам проблеми. Всъщност проблема се появява дори след рестарт от FreeBSD към Линукс.
Ето някои мои наблюдения върху феномена:
1) Грешката се появява само след рестарт от друга операционна система към Линукс.
2) Картата се изключва в абсолютно случаен момент от време - не зависи от мрежовото натоварване, от температурата или от фазата на Венера.
3) Ако се рестартира машината след получаване на грешката, има шанс това пак да се случи. Единствената застраховка - гарантирано че мрежата няма да изчезне - да се мине през пълен shut down. През какъвто и да е рестарт (топъл, студен) или стоп на машината да се мине, има шанс следващия път проблема пак да се появи.

На места намирам препоръка да се изключи tcp segmentation offload (каквото и да значи):

<br />
ethtool -K eth0 tso off<br />

Не върши работа.

Някой казват че проблема е свързан с ACPI и препоръчват в процеса на boot-ване да се добави стринга “noacpi”. Не работи.

Най-тъпото е че Проблема (мисля че си заслужи главната буква) не може да се дебъгне с никакви конвенционални средства. Току изглежда че някаква магическа мантра помага - мрежата не пада… и след Х часа/дни/седмици пак се издъни.

А на всичкото отгоре DNS-a на доставчика ми внезапно спря да прави resolve на ivanatora.info.