Guten Tag liebe Gemeinde,
ich habe aktuell folgendes Problem mit einer FreeBSD 7.0 Maschine auf der Arbeit:
Ich habe als "Datengrab" einen FSC Primgery Server mit FreeBSD 7.0 installiert.
Als Systemfestplatte dient eine stinknormale 160 GB SATA Platte.
Ansonsten sind in der Kiste 4 1 TB Samsung SATA Festplatten verbaut, welche an einem Promise Fasttrack S150 SATA-Controller hängen.
Ich habe diese vier Platten zu einem RaidZ unter ZFS zusammen gefügt und unter /zfs1 ins Dateisystem eingebunden.
Anschließend habe ich über die Ports Samba in der Version 3.0.32 installiert und den Server mittels WinBind an unsere Windows Server 2008 Domäne angebunden.
Innerhalb des RaidZ-Verbundes zfs1 habe ich dann noch zwei Volumes angelegt und diese für den Anfang mit einer Quota von 500 GB versehen..wir wollen ja noch ein bißchen Platz nach oben haben :-)
Das ganze hat soweit super funktioniert, so gut sogar dass ich mir verwundert die Augen reiben musste :-)
Die Aufnahme in die Domäne funzte, das Computerkonto für die BSD-Maschine wurde automatisch erstellt, die NT-Benutzer kommen ohne zusätzliche Authentifizierung mit ihren Active Directory-Credentials auf den Server, die Übergabe der beiden Freigaben per Loginskript funktioniert...alles super..
Was jedoch nicht funktioniert ist die Anzeige des belegten bzw. freien Speicherplatzes auf dem Laufwerk.
Der Windows Explorer zeigt mir hier die kompletten 2,67 TB des RaidZ-Verbundes an, und auch wenn Daten auf das Volume kopiert werden wird als belegter Speicher weiterhin 0 Byte angezeigt.
Auf der BSD-Maschine sehe ich mittels df -h den tatsächlich genutzten Speicherplatz, jedoch wäre es schön wenn die User diese Information ebenfalls wie gewohnt im Explorer sehen könnten.
Mir ist bewusst, dass ZFS unter FreeBSD immer noch ein experimentelles Feature ist, es geht bei den hierbei gespeicherten Daten auch eher um Filme, Musik, temporäre Datensicherungen...also nichts was bei Datenverlust eine große Katastrophe bedeuten würde, daher meine Entscheidung hier ZFS unter FreeBSD einzusetzen...
Ursprünglich sollte die Geschichte unter Solaris 10 bzw. OpenSolaris laufen, jedoch erkannte keines von beiden den verbauten SATA-Controller...ich vermute mal dass es unter OpenSolaris mit der Sun-eigenen CIFS-Implementierung der direkten Freigabe des Volumes über ZFS dieses Problem nicht gegeben hätte.
Aber gut, hat vielleicht jemand dieses Verhalten schon einmal beobachtet und könnte mir hier hilfreiche Tippe geben?
Hier auf jeden Fall schonmal die smb.conf und die aktuelle ZFS-Konfiguration:
smb.conf:
ZFS:
Schonmal vielen Dank im Vorraus,
Dominik
ich habe aktuell folgendes Problem mit einer FreeBSD 7.0 Maschine auf der Arbeit:
Ich habe als "Datengrab" einen FSC Primgery Server mit FreeBSD 7.0 installiert.
Als Systemfestplatte dient eine stinknormale 160 GB SATA Platte.
Ansonsten sind in der Kiste 4 1 TB Samsung SATA Festplatten verbaut, welche an einem Promise Fasttrack S150 SATA-Controller hängen.
Ich habe diese vier Platten zu einem RaidZ unter ZFS zusammen gefügt und unter /zfs1 ins Dateisystem eingebunden.
Anschließend habe ich über die Ports Samba in der Version 3.0.32 installiert und den Server mittels WinBind an unsere Windows Server 2008 Domäne angebunden.
Innerhalb des RaidZ-Verbundes zfs1 habe ich dann noch zwei Volumes angelegt und diese für den Anfang mit einer Quota von 500 GB versehen..wir wollen ja noch ein bißchen Platz nach oben haben :-)
Das ganze hat soweit super funktioniert, so gut sogar dass ich mir verwundert die Augen reiben musste :-)
Die Aufnahme in die Domäne funzte, das Computerkonto für die BSD-Maschine wurde automatisch erstellt, die NT-Benutzer kommen ohne zusätzliche Authentifizierung mit ihren Active Directory-Credentials auf den Server, die Übergabe der beiden Freigaben per Loginskript funktioniert...alles super..
Was jedoch nicht funktioniert ist die Anzeige des belegten bzw. freien Speicherplatzes auf dem Laufwerk.
Der Windows Explorer zeigt mir hier die kompletten 2,67 TB des RaidZ-Verbundes an, und auch wenn Daten auf das Volume kopiert werden wird als belegter Speicher weiterhin 0 Byte angezeigt.
Auf der BSD-Maschine sehe ich mittels df -h den tatsächlich genutzten Speicherplatz, jedoch wäre es schön wenn die User diese Information ebenfalls wie gewohnt im Explorer sehen könnten.
Mir ist bewusst, dass ZFS unter FreeBSD immer noch ein experimentelles Feature ist, es geht bei den hierbei gespeicherten Daten auch eher um Filme, Musik, temporäre Datensicherungen...also nichts was bei Datenverlust eine große Katastrophe bedeuten würde, daher meine Entscheidung hier ZFS unter FreeBSD einzusetzen...
Ursprünglich sollte die Geschichte unter Solaris 10 bzw. OpenSolaris laufen, jedoch erkannte keines von beiden den verbauten SATA-Controller...ich vermute mal dass es unter OpenSolaris mit der Sun-eigenen CIFS-Implementierung der direkten Freigabe des Volumes über ZFS dieses Problem nicht gegeben hätte.
Aber gut, hat vielleicht jemand dieses Verhalten schon einmal beobachtet und könnte mir hier hilfreiche Tippe geben?
Hier auf jeden Fall schonmal die smb.conf und die aktuelle ZFS-Konfiguration:
smb.conf:
Code:
[root@srv0-fbsd /usr/local/etc]# less smb.conf
[global]
workgroup = ADDG
server string = FreeBSD Samba Server
security = DOMAIN
allow trusted domains = No
log file = /var/log/samba/log.%m
max log size = 50
dns proxy = No
wins server = srv-ex2k7.addg.global
ldap ssl = no
#idmap backend = idmap_rid:ADDG=10000-20000
idmap uid = 10000-20000
idmap gid = 10000-20000
template shell = /bin/tcsh
winbind use default domain = Yes
winbind separator = <C2>\
winbind enum users = yes
winbind enum groups = yes
[public]
comment = Public Stuff
path = /zfs1
public = yes
writable = yes
printable = no
nt acl support = yes
ZFS:
Code:
[root@srv0-fbsd /]# zpool status
pool: zfs1
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
zfs1 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 0
errors: No known data errors
[root@srv0-fbsd /]# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
zfs1 3.64T 4.79G 3.63T 0% ONLINE -
Schonmal vielen Dank im Vorraus,
Dominik