- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
-
Az Apple iPadOS-t is megrendszabályozza az EU
it Az EB közölte: az Apple iPad táblagépekre írt iPadOS rendszere is kapuőrnek számít, az üzleti felhasználókra gyakorolt fontossága miatt.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
batagy
őstag
Sziasztok!
Rendszer erőforrás figyelő progik közül mit ajánlanátok?
Konkrétan kettőről már hallottam: Munin és Monit , de egyiket se használtam még, csak kollégák említették.SUSE-n kellene nekem olyan célra valami, hogy bizonyos processek mekkora memóriát és CPU-t használnak. Az alkalmazás service-ként fut, és utólag kell megnézzem a memória/CPU használatot, azaz nem vagyok előtte.
Szóval melyik jobb, Munin vagy Monit, vagy esetleg más? Melyiket egyszerűbb használni? Mi az előnye, hátránya?
Kösz
-
batagy
őstag
válasz
bambano
#15639
üzenetére
"az ntfs-3g az nem userspace fájlrendszer? mert ha igen, akkor azért lassú."
Mi az a userspace fájlendszer?Nálam letöltő gépen OpenSUSE 12.1 fut, Atom procis gépen, és amikor megindul a letöltés, akkor az ntfs-3g processor használata meg szokott ugrani. Gondolom az normális akkor.
-
batagy
őstag
válasz
bambano
#15640
üzenetére
Köszi a választ.
Itthon előbb OpenSUSE-re felnyomtam a Munint, valóban összesített adatokat mutat. Mondjuk ez is nagyon hasznos tud lenni. A gépen csak a mérni kívánt alkalmazás fut, szóval használható.
De nekem valóban nem teljesen ez kell. Lehet hogy valami scriptet kell rá írni, vmstat-tal vagy sar-ral.
-
batagy
őstag
Sziasztok!
Adott egy SLES szerver, amin alapvetően nincs bekapcsolva a tűzfal, és minden port engedélyezve van.
Egy adott portot szeretnék csak blokkolni kifelé. Ezt hogyan tudom megtenni?Pontosabban, egy speciális ipari alkalmazás fut, ami adott NTP szerverhez szinkronizálja az idejét. Azt szeretném, hogy az alkalmazás ne tudja magát az NTP szerverhez szinkronizálni. Az NTP IP-je változhat. Ezért gondoltam hogy az NTP portot lehetne esetleg blokkolni kifelé.
Kösz
[ Szerkesztve ]
-
batagy
őstag
Szia!
Sajnos nem domain név alapján keresi az NTP szervert, hanem IP alapján.
Még sosem használtam az iptables-t!
Gyors gugli alapján valami ilyesmi kell nekem, ha az NTP portot kifelé blokkolni akarom? SLES11:/usr/sbin/iptables -A OUTPUT -p udp --dport 125 -j DROP
/usr/sbin/iptables-saveKérdés:
1. Ez elindítja a tűzfalat, szóval mindenre szűrés lesz?
2. De ez a server saját NTP kliensét is blokkolni fogja igaz? Az viszont úgy nem jó... Csak az alkalmazástól jövő csomagokat szeretném blokkolni.Kösz!
-
batagy
őstag
OK, köszi!
Szerencsére az alkalmazás más speciális usernév alatt fut, így akkor meg tudom oldani!
A kernel verziója 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux.Valóban 123-as az NTP, csak véletlen elírtam.
Egyébként be is adtam, megette:
hostname:~ # iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
hostname:~ #
hostname:~ # /usr/sbin/iptables -A OUTPUT -p udp -m owner --uid-owner specuser --dport 123 -j DROP
hostname:~ #
hostname:~ #
hostname:~ # iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP udp -- anywhere anywhere owner UID match specuser udp dpt:ntp
hostname:~ #
hostname:~ # /usr/sbin/iptables-save
# Generated by iptables-save v1.4.2-rc1 on Tue Dec 18 20:10:53 2012
*filter
:INPUT ACCEPT [57148674:8162131162]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [35318506:186552967608]
-A OUTPUT -p udp -m owner --uid-owner specuser -m udp --dport 123 -j DROP
COMMIT
# Completed on Tue Dec 18 20:10:53 2012
hostname:~ #De nem teszteltem még!
[ Szerkesztve ]
-
batagy
őstag
Kösz!
Még annyi infó, SLES11-en nincs iptables service, sőt az /etc/init.d alatt se találok ilyen service-t.
Viszont nekem úgy tűnik, hogy maga a beállítás el is indította, mert ha yast-tal bele akarok menni a Firewall beállításokba, kiír egy üzenetet, hogy egy másik firewall már fut a gépen! Szóval valahogy detektálja a Yast ezt.
-
batagy
őstag
Sziasztok!
Olyat lehet csinálni, hogy egy bináris (már compilált) kernel modult egyik oprendszerről átmásolok egy másik, ugyanolyan oprendszerre? Utóbbiban talán nem lett belefordítva az a funkció.
Konkrétan, hogy ne rébuszokban beszéljek:
SUSE Enterprise 11 SP2.
Kernel:
hostname1:~ # uname -a
Linux hostname1 3.0.74-0.6.8-default #1 SMP Wed May 15 07:26:33 UTC 2013 (5e244d7) x86_64 x86_64 x86_64 GNU/Linux
hostname1:~ #A "zram" nevű kernel modult szeretném ezen az oprendszeren használni. A 3-as kernelben már integrálva van ez a funckió, de ezen a SUSE enterprise-on nem elérhető, vagy nem lett belefordítva.
A zram modult nem tudom betölteni:
hostname1:~ # modprobe zram num_devices=4
FATAL: Module zram not found.
hostname1:~ #A forráskódja megtalálható az /usr/src-ben:
hostname1:~ # cd /usr/src/linux-3.0.74-0.6.8/drivers/staging/zram/
hostname1:/usr/src/linux-3.0.74-0.6.8/drivers/staging/zram # ls -la
total 76
drwxr-xr-x 2 root root 4096 Sep 10 13:09 .
drwxr-xr-x 67 root root 4096 Sep 10 13:09 ..
-rw-r--r-- 1 root root 821 May 15 09:26 Kconfig
-rw-r--r-- 1 root root 100 May 15 09:26 Makefile
-rw-r--r-- 1 root root 12896 May 15 09:26 xvmalloc.c
-rw-r--r-- 1 root root 774 May 15 09:26 xvmalloc.h
-rw-r--r-- 1 root root 1980 May 15 09:26 xvmalloc_int.h
-rw-r--r-- 1 root root 1987 May 15 09:26 zram.txt
-rw-r--r-- 1 root root 16494 May 15 09:26 zram_drv.c
-rw-r--r-- 1 root root 3434 May 15 09:26 zram_drv.h
-rw-r--r-- 1 root root 5350 May 15 09:26 zram_sysfs.c
hostname1:/usr/src/linux-3.0.74-0.6.8/drivers/staging/zram #Na, most, egy másik SLES11 SP2 szerveren érdekes módon ez a modul le lett fordítva, ott megtaláltam a zram.ko modult:
hostname2 [12:05pm] [/home/batagy] -> ls -l /lib/modules/3.0.74-0.6.8-default/kernel/drivers/staging/zram/
total 32
-rw-r--r-- 1 root root 28952 May 15 14:04 zram.ko
hostname2 [12:06pm] [/home/batagy] -> modprobe zram
FATAL: module '/lib/modules/3.0.74-0.6.8-default/kernel/drivers/staging/zram/zram.ko' is unsupported
Use --allow-unsupported or set allow_unsupported_modules to 1 in
/etc/modprobe.d/unsupported-modules
hostname2 [12:06pm] [/home/batagy] ->A másik rendszerben ugyanaz a kernel verzió és az architektúra is, mindkettő Intel Xeon x86_64. Csak ez utóbbiban úgy tűnik le lett fordítva a zram modul.
A kérdés: ha a zram.ko modult a második gépről átmásolom az első gépbe a /lib/modules/3.0.74-0.6.8-default/kernel/drivers/staging/zram/ mappába, akkor mi történik?
Működik ez így, vagy a kernelt eleve úgy kell fordítani?
Kösz!
-
batagy
őstag
válasz
Jester01
#18522
üzenetére
Hali!
Érdekes, hogy az SLES11 SP2-n nincs benne a ZSMALLOC függőség:
hostname1:~ # cat /usr/src/linux-3.0.74-0.6.8/drivers/staging/zram/Kconfig
config XVMALLOC
bool
default n
config ZRAM
tristate "Compressed RAM block device support"
depends on BLOCK && SYSFS
select XVMALLOC
select LZO_COMPRESS
select LZO_DECOMPRESS
default n
help
Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
Pages written to these disks are compressed and stored in memory
itself. These disks allow very fast I/O and compression provides
good amounts of memory savings.
It has several use cases, for example: /tmp storage, use as swap
disks and maybe many more.
See zram.txt for more information.
Project home: http://compcache.googlecode.com/
config ZRAM_DEBUG
bool "Compressed RAM block device debug support"
depends on ZRAM
default n
help
This option adds additional debugging code to the compressed
RAM block device driver.
hostname1:~ #Átmásoltam a binárist és megpróbáltam betölteni, de nem sikerül neki:
hostname1:~ # ls -l /lib/modules/3.0.74-0.6.8-default/kernel/drivers/staging/zram/
total 32
-rw-r--r-- 1 root root 28952 Nov 11 12:14 zram.ko
hostname1:~ # modprobe /lib/modules/3.0.74-0.6.8-default/kernel/drivers/staging/zram/zram.ko
FATAL: Module /lib/modules/3.0.74_0.6.8_default/kernel/drivers/staging/zram/zram.ko not found.
hostname1:~ # modprobe zram num_devices=4
FATAL: Module zram not found.
hostname1:~ #Merrefelé induljak tovább?
(#18523) sch_a
Az tuti hogy nem elegáns, eléggé gányolásnak tűnik, de a szükség rávisz. Valóban az a kérdés hogy okoz-e gondot. -
batagy
őstag
válasz
a 9. utas
#18527
üzenetére
Sajnos nem a kötőjel-aláhúzás a gond, mert anélkül se megy:
hostname1:~ # modprobe /root/home/batagy/zram.ko num_devices=4
FATAL: Module /root/home/batagy/zram.ko not found.
hostname1:~ #"A két rendszeren teljesen azonos a kernel?"
Az "uname -a" kimenete karakterre ugyanaz. De az lehetséges hogy más opciók lettek belefordítva a kettőbe."Mert eltérő verziók esetén semmi biztosíték nincs rá, hogy egy ilyen másolgatás működni fog"
Igen, ez egyértelmű.A modprobe kísérlet után a dmesg és a /var/log/messages se ír semmit.
Nem lehet hogy valami LIB-szerű környezeti változóba kell beletenni az elérési utat?[ Szerkesztve ]
-
batagy
őstag
A kernelt kellene újrafordítani? Vagy csak a modult magát?
Nos, kernelt még sosem fordítottam. Ha egyszerű, esetleg meg is próbálnám, de nem tudom mivel jár. Alapvetően itt az a gond, hogy ez egy céges szerver és egy másik cég (HP) tartja fönn az oprendszert. Root jogom ugyan van, és egyszerű módosítások talán még beleférnek, de egy kernel fordítást már neccesnek érzek. Nem tudom hogy mennyire egyszerű vagy hogyan tudjuk kontrollállni azt, hogy mi kerül bele.
Közben rájöttem, hogy modprobe paranccsal nem megy, de insmod paranccsal valami mégis történik:
hostname1:~ # insmod /root/home/batagy/zram.ko
hostname1:~ # lsmod | grep lzo
hostname1:~ # lsmod | grep zram
zram 18589 0
hostname1:~ #
hostname1:~ #Utána dmesg:
[250862.537778] zram: module is from the staging directory, the quality is unknown, you have been warned.
[250862.546045] zram: num_devices not specified. Using default: 1
[250862.546048] zram: Creating 1 devices .../var/log/messages:
Nov 11 14:00:02 esesslx0127 kernel: [250862.537778] zram: module is from the staging directory, the quality is unknown, you have been warned.
Nov 11 14:00:02 esesslx0127 kernel: [250862.546045] zram: num_devices not specified. Using default: 1
Nov 11 14:00:02 esesslx0127 kernel: [250862.546048] zram: Creating 1 devices ...
Nov 11 14:00:02 esesslx0127 multipathd: zram0: add path (uevent)
Nov 11 14:00:02 esesslx0127 multipathd: zram0: HDIO_GETGEO failed with 25
Nov 11 14:00:02 esesslx0127 multipathd: /lib/udev/scsi_id exitted with 1
Nov 11 14:00:02 esesslx0127 multipathd: /lib/udev/scsi_id exitted with 1
Nov 11 14:00:02 esesslx0127 multipathd: zram0: failed to get path uid
Nov 11 14:00:02 esesslx0127 multipathd: uevent trigger errorAhogy nézem, mégiscsak valami működik, viszont a multipath daemon-nal is összefügg a működés, úgy tűnik.
[ Szerkesztve ]
-
batagy
őstag
válasz
a 9. utas
#18535
üzenetére
Ok.
A kötőjel-aláhúzás része végül is mindegy.
A lényeg hogy "insmod" paranccsal megy!A multipath daemon konfigjéban a zram-ot blacklist-re tettem, így nem érinti!
/etc/multipath.conf
Eredeti :blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"Módosított:
blacklist {
devnode "^(ram|zram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"reboot
utána, ha insmod-dal berakom a zram modult, akkor már nem panaszkodik a multipath daemon.
[ Szerkesztve ]
-
batagy
őstag
válasz
Jester01
#18538
üzenetére
Valóban!
hostname1:~ # depmod -a
hostname1:~ # lsmod | grep zram
zram 18589 0
hostname1:~ # modprobe zram
hostname1:~ #Köszi!
Amúgy, ha újra akarnám fordítani csak a modult önmagában (nem a kernelt), az hogyan menne? Mert teljes Makefile nincs a forráskód mappában.
A Makefile tartalma ennyi:
hostname1:~ # cat /usr/src/linux-3.0.74-0.6.8/drivers/staging/zram/Makefile
zram-y := zram_drv.o zram_sysfs.o
obj-$(CONFIG_ZRAM) += zram.o
obj-$(CONFIG_XVMALLOC) += xvmalloc.o
hostname1:~ # -
batagy
őstag
Sziasztok!
OpenSUSE 13.1 friss telepítésű gépet mint NIS klienst szeretnék beintegrálni egy meglévő NIS szerverbe. A NIS szerver Solaris 10-en fut.
Más SLES10 SP2-es szerverek már integrálva vannak régóta, azokon működik rendesen a NIS.Az a probléma, hogy a jelszót nem fogadja el, ha egy NIS user belép.
Hibaüzenet a /var/log/messages-ban:2014-05-19T17:45:34.287130+02:00 seag sshd[42440]: error: PAM: Authentication service cannot retrieve authentication info for egyobat from
2014-05-19T17:45:35.083873+02:00 seag sshd[42440]: error: Received disconnect from : 13: Unable to authenticate [preauth]Yast-tal beállítottam először az NFS kliens-t, mert a user home-okat előtte fel kell mountolni. Ezzel nincs gond.
NFS kliens esetén a Yast az alábbi fájlokat módosítja:
/etc/sysconfig/nfs
/etc/idmapd.conf
/etc/fstabUtána Yast-tal beállítottam a NIS-t. A Yast az alábbi fájlokat módosítja:
/etc/sysconfig/network/config
/etc/nsswitch.conf
/etc/group
/etc/shadow
/etc/passwd
/etc/sysconfig/ypbind
/etc/yp.confInnentől működnie kellene, de nem akar. Működne, de a NIS user jelszót nem fogadja el.
Akkor működik a belépés, ha az nscd service-t leállítom!systemctl status nscd.service
systemctl stop nscd.serviceDe amint elindítom az nscd-t, nem fogadja el a jelszót. Variáltam többféleképpen a /etc/nsswitch.conf tartalmát és az /etc/shadow utolsó sorát, de csak akkor megy ha az nscd le van állítva.
Az /etc/nsswitch.conf tartalma:
passwd: compat
group: compat
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files dns
services: files nis
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files
bootparams: files
automount: files
aliases: files nis
shadow: compatAz /etc/shadow-ba a Yast alapból csak egy "+" jelet tesz az utolsó sorba. Én próbáltam "+::::::::"-tal is, de a szitu ugyanaz.
A "getent passwd" és "ypcat passwd" lefut rendesen, kiírja az összes NIS usert. Érdekes módon a "getent passwd" a jelszót hash-eket is beleveszi a printoutba, míg a "ypcat passwd" a jelszó hash-eket nem írja ki, de ez így van a két régi SLES10 gépen is.
Van ötletetek?
SZERK: bocs, nem Lenry -nek akartam címezni, csak véletlen a válaszra kattintottam.
[ Szerkesztve ]
-
batagy
őstag
válasz
syler123
#23172
üzenetére
Én is követem ám az eseményt.
Szerintem:
1. Win alatt a partíciós táblát konvertált át MBR-ről GPT-re és NTFS-sel formázd. Szerintem nem kell full format, csak gyors.
(Én mondjuk Linux Mint alatt, Gparted-del az MBR a partíciós tábla törölném, és ott állítanám be a GPT-t és az NTFS formázást, de ha biztosra akarsz menni, akkor Win alatt.)2. Utána a Linux Mint alatt, Gparted-del a GPT-t visszatörölném és MBR-re visszaállítanám, és NTFS helyett EXT4-et állítanék be.
3. Utána OpenWRT-n csekkolni a rackben USB-n. Illetve Linux Mint alatt USB-n is.
4. Ha megint readonly lesz a dmesg hibák miatt, akkor a vinyót USB helyett natív SATA-ben próbálnám rákötni a gépre, hogy ott látszik-e a dmesg hiba és readonly lesz-e. Nincs mondjuk eSATA csatlakozó a gépen? Arra is lehetne kötni. Így ugyanis kizárható lenne, hogy a Jmicron rack okozza-e a hibát.
Amúgy BUÉK!
[ Szerkesztve ]
-
batagy
őstag
válasz
syler123
#23178
üzenetére
Jó, csak akkor megpróbálok egy konklúziót összefoglalni:
- Tehát akkor továbbra sem tudjuk hogy a JMS566 chipes rack okozta-e a readonly mountolást EXT4 esetén, merthogy ugyanaz a vinyó más módon nem volt csatlakoztatva.
- Mindenesetre a Journal kikapcsolása megoldja az EXT4 mountolást.Nekem is van ugyanolyan rackem, és vinyóm is amivel tesztelni is tudom, most már kíváncsivá tettél. De csak majd ha kedvem lesz....
-
batagy
őstag
válasz
syler123
#23181
üzenetére
Nem hagyott nyugodni, és leteszteltem magam is.
Rack: noname Ebay-jes Jmicron JMS566 chipes. VID-PID: 152D-3569.
Firmware verzió: 00.01.01.04Vinyó: Hitachi HTS721080G9SA00.
OpenSUSE 13.2 (kernel 3.16.7-21) rendszeren , Gparted-ben létrehoztam rajta EXT4 partíciót (MBR). USB2-n csatlakoztatva. Utána le és felcsatolás, és semmi gond, írható. Csupán jogosoltsági probléma volt, mert a mountolás gyökerébe csak a root írhatott, user nem, de ezt egy chmod 777 megoldotta.
Logok:
batagy@sesame:~> uname -a
Linux sesame 3.16.7-21-desktop #1 SMP PREEMPT Tue Apr 14 07:11:37 UTC 2015 (93c1539) x86_64 x86_64 x86_64 GNU/Linux
batagy@sesame:~>
sesame:/var/run/media/batagy# dmesg -e
...
[Jan 1 16:45] usb 1-1.2: USB disconnect, device number 3
[ +0.001515] sd 8:0:0:0: [sdc] Synchronizing SCSI cache
[ +0.089788] sd 8:0:0:0: [sdc]
[ +0.000006] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ +19.120912] usb 1-1.2: new high-speed USB device number 4 using ehci-pci
[ +0.166619] usb 1-1.2: New USB device found, idVendor=152d, idProduct=3569
[ +0.000012] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0.000003] usb 1-1.2: Product: USB to ATA/ATAPI Bridge
[ +0.000002] usb 1-1.2: Manufacturer: JMicron
[ +0.000002] usb 1-1.2: SerialNumber: DB123456789B3E
[ +0.001811] scsi9 : uas
[ +0.000724] scsi 9:0:0:0: Direct-Access ADplus SuperVer 0114 PQ: 0 ANSI: 6
[ +0.001352] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ +0.000489] sd 9:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[ +0.000004] sd 9:0:0:0: [sdc] 4096-byte physical blocks
[ +0.001383] sd 9:0:0:0: [sdc] Write Protect is off
[ +0.000006] sd 9:0:0:0: [sdc] Mode Sense: 53 00 10 08
[ +0.000591] sd 9:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ +0.032919] sdc: sdc1
[ +0.003239] sd 9:0:0:0: [sdc] Attached SCSI disk
[Jan 1 16:46] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
[ +3.578891] sdc1: WRITE SAME failed. Manually zeroing.
sesame:/var/run/media/batagy #
sesame:/var/run/media/batagy # df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda5 ext4 32G 4.9G 26G 16% /
devtmpfs devtmpfs 3.8G 8.0K 3.8G 1% /dev
tmpfs tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs tmpfs 3.8G 2.2M 3.8G 1% /run
tmpfs tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda2 vfat 95M 32M 64M 33% /boot/efi
/dev/sdc1 ext4 74G 52M 70G 1% /run/media/batagy/testext4
sesame:/var/run/media/batagy #
sesame:/var/run/media/batagy # mount | grep sdc
/dev/sdc1 on /run/media/batagy/testext4 type ext4 (rw,nosuid,nodev,relatime,stripe=8191,data=ordered,uhelper=udisks2)
sesame:/var/run/media/batagy #Utána Synology NAS-on (kernel 3.2.40) is megnéztem USB2-es portban, ott sincs semmi gondja.
Logok:DiskStation> uname -a
Linux DiskStation 3.2.40 #5592 Wed Aug 19 16:32:46 CST 2015 armv7l GNU/Linux synology_armada370_213j
DiskStation>
DiskStation> dmesg
...
[62086.990464] usb 1-1: new high-speed USB device number 7 using ehci_marvell
[62087.174882] scsi15 : usb-storage 1-1:1.0
[62088.171438] scsi 15:0:0:0: Direct-Access ADplus SuperVer 0114 PQ: 0 ANSI: 6
[62088.183675] sd 15:0:0:0: Attached scsi generic sg1 type 0
[62088.190189] sd 15:0:0:0: [sdq] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[62088.204691] sd 15:0:0:0: [sdq] Write Protect is off
[62088.209606] sd 15:0:0:0: [sdq] Mode Sense: 47 00 10 08
[62088.217225] sd 15:0:0:0: [sdq] Write cache: enabled, read cache: enabled, supports DPO and FUA
[62088.263586] sdq: sdq1
[62088.270406] sd 15:0:0:0: [sdq] Attached SCSI disk
[62090.107803] EXT3-fs (sdq1): error: couldn't mount because of unsupported optional features (240)
[62090.153083] EXT4-fs (sdq1): barriers disabled
[62090.197791] EXT4-fs (sdq1): mounted filesystem with ordered data mode. Opts: nodelalloc,synoacl,data=ordered,oldalloc
DiskStation>
DiskStation> df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.4G 608M 1.7G 27% /
/tmp 249M 136K 249M 1% /tmp
/run 249M 1.8M 248M 1% /run
/dev/shm 249M 0 249M 0% /dev/shm
/dev/vg1000/lv 455G 87G 368G 20% /volume1
/dev/sdq1 74G 180M 70G 1% /volumeUSB1/usbshare
DiskStation> mount
/dev/root on / type ext4 (defaults)
/sys on /sys type sysfs (0)
none on /dev/pts type devpts (gid=4,mode=620)
/tmp on /tmp type tmpfs (0)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
/proc/bus/usb on /proc/bus/usb type usbfs (0)
/dev/vg1000/lv on /volume1 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl)
securityfs on /sys/kernel/security type securityfs (0)
none on /proc/fs/nfsd type nfsd (0)
/dev/sdq1 on /volumeUSB1/usbshare type ext4 (nodelalloc,synoacl)
DiskStation>Nem tudom hogy a Synology-n a Journal be volt-e kapcsolva.
OpenWRT-m nincs, csak Gargoyle routerem, de azon nem néztem meg.Szóval nálam nem okozott gondot az EXT4 a JMS566-tal. Szerintem nem hibás ez a chip. Sajnos nem tudom nálad mi lehetett.
[ Szerkesztve ]
-
#23188
batagy
őstag
King Unique
#23187
batagy
őstag
válasz
King Unique
#23187
üzenetére
Ebben mondjuk nem értek veled egyet, külső HDD-t és USB-s racket miért ne lehetne routerrel vagy TV-vel használni, nincs az külön tervezve csak desktophoz.
Az adott probléma valamilyen OS vagy valamilyen SW beállítási probléma lehet.
Amúgy a fentebbi Synology-s dmesg logomban van egy érdekes, ez a barrier hibaüzenet:
[62090.107803] EXT3-fs (sdq1): error: couldn't mount because of unsupported optional features (240)
[62090.153083] EXT4-fs (sdq1): barriers disabledFogalmam sincs mit jelent a barrier, de valamilyen összefüggés biztosan van a Journaling-gal. Ha ezt vesszük, lehet hogy valamilyen barrier vagy journaling dolgot nem kezelnek bizonyos linuxok. Nem olvastam el ezt a cikket, de lehetséges hogy az OpenWRT emiatt vette a fájlrendszert sérültnek. További cikk1, cikk2, cikk3.
Ha valaki érti ezeket, esetleg homályosítson fel minket.
[ Szerkesztve ]
-
batagy
őstag
válasz
CPT.Pirk
#23194
üzenetére
Értem.
Az látszik, hogy a Synology NAS valamiért magától használja a nobarrier flag-et. Az OpenSUSE-nél ugyanakkor ez nem látszik, azaz úgy tűnik barrier-t használ.
Ettől függetlenül, az kérdés merült fel bennem, hogy a Jmicron JMS566 USB vezérlő (vagy akár más USB vezérlők) esetleg a journalt vagy a barriert nem támogatják, és olyankor az OS-en múlik hogy ezt hogyan kezeli le.
Most ugyanazt a tesztet végrehajtottam, mint korábban a JMS566 chipes rackkel, csak most ASmedia ASM1053 (VID PID 174C-5136) vezérlős rackben. Vinyó és minden más ugyanaz.
OpenSUSE 13.2 (kernel 3.16.7-21):
batagy@sesame:~> uname -a
Linux sesame 3.16.7-21-desktop #1 SMP PREEMPT Tue Apr 14 07:11:37 UTC 2015 (93c1539) x86_64 x86_64 x86_64 GNU/Linux
batagy@sesame:~>
batagy@sesame:~> dmesg -e
...
[ +43.107817] usb 1-1.1: new high-speed USB device number 3 using ehci-pci
[ +0.144949] usb 1-1.1: New USB device found, idVendor=174c, idProduct=5136
[ +0.000013] usb 1-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ +0.000002] usb 1-1.1: Product: AS2105
[ +0.000002] usb 1-1.1: Manufacturer: ASMedia
[ +0.000002] usb 1-1.1: SerialNumber: 00000000000000000000
[ +0.000513] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ +0.001108] scsi14 : usb-storage 1-1.1:1.0
[ +1.003109] scsi 14:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6
[ +0.002363] sd 14:0:0:0: Attached scsi generic sg3 type 0
[ +1.487540] sd 14:0:0:0: [sdc] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[ +0.001103] sd 14:0:0:0: [sdc] Write Protect is off
[ +0.000013] sd 14:0:0:0: [sdc] Mode Sense: 43 00 00 00
[ +0.001092] sd 14:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ +0.020322] sdc: sdc1
[ +0.004053] sd 14:0:0:0: [sdc] Attached SCSI disk
[Jan 2 14:13] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
batagy@sesame:~>
batagy@sesame:~> df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda5 ext4 32G 4.9G 26G 16% /
devtmpfs devtmpfs 3.8G 8.0K 3.8G 1% /dev
tmpfs tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs tmpfs 3.8G 2.2M 3.8G 1% /run
tmpfs tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda2 vfat 95M 32M 64M 33% /boot/efi
/dev/sdc1 ext4 74G 52M 70G 1% /run/media/batagy/testext4
űbatagy@sesame:~>
batagy@sesame:~> mount | grep sdc
/dev/sdc1 on /run/media/batagy/testext4 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
batagy@sesame:~>
batagy@sesame:~/Desktop> cat /proc/mounts | grep sdc
/dev/sdc1 /run/media/batagy/testext4 ext4 rw,nosuid,nodev,relatime,data=ordered 0 0
batagy@sesame:~/Desktop>Synology NAS-on (kernel 3.2.40):
DiskStation> dmesg
...
[ 2348.386831] usb 2-1: new high-speed USB device number 2 using ehci_marvell
[ 2348.571966] scsi2 : usb-storage 2-1:1.0
[ 2349.567800] scsi 2:0:0:0: Direct-Access ASMT 2105 0 PQ: 0 ANSI: 6
[ 2349.580037] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 2351.167746] sd 2:0:0:0: [sdq] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
[ 2351.176598] sd 2:0:0:0: [sdq] Write Protect is off
[ 2351.181441] sd 2:0:0:0: [sdq] Mode Sense: 43 00 00 00
[ 2351.182994] sd 2:0:0:0: [sdq] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2351.215155] sdq: sdq1
[ 2351.246244] sd 2:0:0:0: [sdq] Attached SCSI disk
[ 2353.002538] EXT3-fs (sdq1): error: couldn't mount because of unsupported optional features (240)
[ 2353.054832] EXT4-fs (sdq1): barriers disabled
[ 2353.107836] EXT4-fs (sdq1): mounted filesystem with ordered data mode. Opts: nodelalloc,synoacl,data=ordered,oldalloc
DiskStation>
DiskStation> df -HT
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 2.6G 639M 1.8G 27% /
/tmp tmpfs 262M 132k 261M 1% /tmp
/run tmpfs 262M 1.5M 260M 1% /run
/dev/shm tmpfs 262M 0 262M 0% /dev/shm
/dev/vg1000/lv ext4 488G 81G 408G 17% /volume1
/dev/sdq1 ext4 79G 189M 75G 1% /volumeUSB1/usbshare
DiskStation>
DiskStation> mount | grep sdq
/dev/sdq1 on /volumeUSB1/usbshare type ext4 (nodelalloc,synoacl)
DiskStation>
DiskStation> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,user_xattr,barrier=1,journal_checksum,data=ordered 0 0
none /dev devtmpfs rw,nosuid,noexec,relatime,size=250740k,nr_inodes=62685,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
/tmp /tmp tmpfs rw,relatime 0 0
/run /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
/dev/shm /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/vg1000/lv /volume1 ext4 rw,relatime,user_xattr,synoacl,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0
securityfs /sys/kernel/security securityfs rw,relatime 0 0
none /proc/fs/nfsd nfsd rw,relatime 0 0
/dev/sdq1 /volumeUSB1/usbshare ext4 rw,relatime,user_xattr,synoacl,barrier=0,journal_checksum,nodelalloc,data=ordered 0 0
DiskStation>Eredmény ugyanaz, különbséget a JMS566 chip és az ASM1053 chip között nem látok a barrier szempontjából. Az biztos, hogy a Synology NAS valamiért magától használja a nobarrier flag-et. Ráadásul nemcsak az USB-s külső vinyóhoz használja a nobarrier-t, hanem a belső saját vinyóhoz is.
Lehetséges az., hogy (legalábbis ez a két USB-s vezérlő) nem támogatja a journal-t és/vagy barrier-t az EXT4-en, és esetleg az OpenWRT és a Linux Mint ezt nem tudja magától lekezelni, csak akkor ha a journal kikapcsolásra kerül? Vagy ez hülyeség?
-
-
batagy
őstag
válasz
Jester01
#23220
üzenetére
Kernel verzió mi a laptop1 és laptop2 esetén? Nem esetleg a laptop2 újabb?
Ez alapján, esetleg próbáld meg USB2.0 portban is, a laptop1-en, illetve Legacy supporton engedélyezni a BIOSban az USB3 portokra.. (?)
Ettől még lehet az Asmedia firmware is hiányos. Kár hogy a PID-ed 1153, így nem frissíthető.
-
batagy
őstag
Sziasztok!
Oracle supporthoz van itt valakinek érvényes hozzáférése?
Sun szerverekhez keresek firmware-t.
Konkrétan az alábbi firmware-eket keresem.1) SunFire T5240: SysFW 7.4.10.a = 147310-14
2) SunFire X4240: 3.2.2 = ILOM 3.0.6.16.b r100130Az Oracle support oldal csak akkor enged be, ha van érvényes support szerződés.
