freenas 5.9TB bestand maken

[Dutch2007]

sinds kort lees: dinsdag

heb ik een op freenas gebaseerde fileserver..

HDD's: 4x 2TB seagate schijven

heb in de freenas webconfig panel, de 4 schijven middels zfs + Raid-Z gekoppeld, wat een effectieve schijfruimte van 5.9TB overhoud.

freenas bied middels Iscsci 2 manieren om zaken te delen... via een schijf of via een file op een (virtual) disk.

Daar ik 4x 2TB heb, en de nas/san met meer dan 1 pc wil delen, kan ik niet kiezen voor de hdd optie (deze zijn al geclaimed door freenas 0.8)

dus moet ik kiezen voor de mount to file optie...

waardoor ik dus het volgende op de /mnt/lun/ uitgevoerd..

login as: xxxxx
xxxxx@192.168.1.130's password:
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

FreeBSD 8.2-RELEASE-p1 (FREENAS.amd64) #4: Sat Apr 30 10:39:46 PDT 2011

FreeNAS nanobsd (c) 2009-2010, The FreeNAS Development Team
All rights reserved.
FreeNAS is under the modified BSD license.

For more information, documentation, help or support, go here:
http://freenas.org
Welcome to FreeNAS
Could not chdir to home directory /nonexistent: No such file or directory
[xxxxx@freenas /]$ sudo
-bash: sudo: command not found
[xxxxx@freenas /]$ cd /mnt
[xxxxx@freenas /mnt]$ ls
lun md_size
[xxxxx@freenas /mnt]$ cd lun
[xxxxx@freenas /mnt/lun]$ dd if=/dev/zero iscsi=1k count = 590M
dd: unknown operand iscsi
[xxxxx@freenas /mnt/lun]$ dd if=/dev/zero of=iscsi=1k count = 590M
dd: unknown operand count
[xxxxx@freenas /mnt/lun]$ dd if=/dev/zero of=iscsi bs=1k count = 590M
dd: unknown operand count
[xxxxx@freenas /mnt/lun]$ dd if=/dev/null of=iscsi bs=1k count = 590M
dd: unknown operand count
[xxxxx@freenas /mnt/lun]$ dd if=/dev/null of=iscsi bs=1k count =590M
dd: unknown operand count
[xxxxx@freenas /mnt/lun]$ dd if=/dev/null of=iscsi bs=1k count=590M
dd: iscsi: Permission denied
[xxxxx@freenas /mnt/lun]$ sudo dd if=/dev/null of=iscsi bs=1k count=590M
-bash: sudo: command not found
[xxxxx@freenas /mnt/lun]$ su dd if=/dev/null of=iscsi bs=1k count=590M
su: Sorry
[xxxxx@freenas /mnt/lun]$ su
Password:
freenas# dd if=/dev/null of=iscsi bs=1k count=590M
0+0 records in
0+0 records out
0 bytes transferred in 0.000164 secs (0 bytes/sec)
freenas# dd if=/dev/zero of=iscsi bs=1k count=590M
618659840+0 records in
618659840+0 records out
633507676160 bytes transferred in 3933.654324 secs (161048131 bytes/sec)
freenas# freenas# dd if=/dev/zero of=iscsi bs=1k count=590M
freenas# 618659840+0 records in
freenas# 618659840+0 records out
freenas# 633507676160 bytes transferred in 3933.654324 secs (161048131 bytes/sec)

freenas#

633507676160 bytes is echter slechts 0.576171875 Terrabyte en dus geen 5.9TB (wat ik dus wel wil, dan kan ik deze mooi als 1 grote disk gebruiken op 3-4 pc's)

[himlims_]

weet niet wat 590M is, maar dat is iig geen 5.9TB

[Herko_ter_Horst]

590M * 1KiB = 590GiB ( = 633.507.676.160 bytes), geen 5,9TiB.

[ Voor 28% gewijzigd door Herko_ter_Horst op 12-05-2011 14:11 ]

[Dutch2007]

welke raden jullie aan?

dd if=/dev/zero of=iscsi bs=10k count=590M

of

dd if=/dev/zero of=iscsi bs=1k count=5900M ???

[ Voor 10% gewijzigd door Dutch2007 op 12-05-2011 14:23 ]

[CAPSLOCK2000]

vuistregel: grotere blocks zijn sneller.
Moderne HD's werken zelf met blokjes van 4k. Onder de 4K gaan heeft dus sowieso weinig zin.
De rest van je systeem werkt waarschijnlijk met nog grotere blokken. Hoe groter het blok, hoe minder vaak er iets gedaan hoeft te worden, hoe minder overhead, hoe meer performance.

Zelf gebruik ik meestal blokken van 1M, dat rekent lekker makkelijk.

[Xiphalon]

exporteer je ZVOL?

[Dutch2007]

dd if=/dev/zero of=iscsi bs=1M count=5900

bovenstaande zou het dan moeten zijn? 5900 blokjes van ieder 1MB....

[Herko_ter_Horst]

Is het met de block size niet zo dat dat gelijk de minimale ruimte is die een bestand inneemt? Dus met een block size van 1M neemt een file van 10K ook 1M in?

[leuk_he]

Herko_ter_Horst schreef op donderdag 12 mei 2011 @ 14:59:
Is het met de block size niet zo dat dat gelijk de minimale ruimte is die een bestand inneemt? Dus met een block size van 1M neemt een file van 10K ook 1M in?

Blokken op je filesysteem wel. Maar hier gaat het gewoon hoe veel gebeugen dd gebruikt, en dat heeft geen invloed op de de blockgrotte van je FS.


Overigens kun je toch ook een volume maken en dat exporteren? (zit niet in gui... maar beetje typen kan geen kwaad)

http://sourceforge.net/ap...viewtopic.php?f=53&t=3746

Of loop je dan tegen een 2Tb limiet aan op freenas (link op forum daar is wellicht te oud.

[ Voor 3% gewijzigd door leuk_he op 12-05-2011 15:11 ]

[Dutch2007]

Ik ga het voor films e.d. gebruiken dus er zullen nagenoeg geen kleine files op komen te staan...

[deadinspace]

Dutch2007 schreef op donderdag 12 mei 2011 @ 14:22:
welke raden jullie aan?

dd if=/dev/zero of=iscsi bs=10k count=590M

of

dd if=/dev/zero of=iscsi bs=1k count=5900M

Tip: Gebruik [code] of [cmd] blokken voor dit soort dingen in plaats van [quote] blokken

En het maakt kort door de bocht gezegd geen zak uit. De eerste gebruikt iets meer geheugen (namelijk 9KB meer) maar zal iets minder CPU gebruiken. In beide gevallen zal de harddisk hoogstwaarschijnlijk toch de performance-bottleneck zijn.

CAPSLOCK2000 schreef op donderdag 12 mei 2011 @ 14:27:
vuistregel: grotere blocks zijn sneller. [...] Hoe groter het blok, hoe minder vaak er iets gedaan hoeft te worden, hoe minder overhead, hoe meer performance.

Dat klopt, dd moet voor elke block een system call maken, en system calls kosten relatief veel tijd. Wel is het zo dat je de blocks ook beter weer niet te groot kunt maken, want zodra ze niet meer in de cache van je CPU passen gaat de performance weer omlaag.

Op mijn systeem (core2duo) doet een dd van /dev/zero naar /dev/null ongeveer 11GB/sec voor block sizes van 16K tot 1M, maar bij blocks van 8M is dat ineens nog maar 3GB/sec.

Overigens zijn dit soort dingen redelijk onbelangrijk als het om schrijven naar een harddisk gaat; de harddisk is vrijwel altijd de bottleneck met zijn hoogstens 100MB/sec
Daarom zou ik in dat soort situaties blocks van 1K of 1M gebruiken, dat rekent het makkelijkst en de performance is in beide gevallen ruimschoots goed genoeg.

Moderne HD's werken zelf met blokjes van 4k.

Sommigen inderdaad wel, maar daar merk je niks van, want ATA praat nog gewoon in sectoren van 512 bytes. Er zijn wel wat geluiden dat men dat in ATA ook op wil rekken naar 4K, maar daar is voorzover ik weet nog niks concreets van terecht gekomen.

Dutch2007 schreef op donderdag 12 mei 2011 @ 14:55:
dd if=/dev/zero of=iscsi bs=1M count=5900

bovenstaande zou het dan moeten zijn? 5900 blokjes van ieder 1MB....

Dat is dus 5.9GB he

[Dutch2007]

heb nu iif de dd lopen, is al rond de 60%

cpu is een 2100 intel i3 met 4GB ram

[Kees]

En ga je die dan via iscsi exporteren en op 3-4 clients gelijktijdig gebruiken?

[leuk_he]

Kees schreef op donderdag 12 mei 2011 @ 21:12:
En ga je die dan via iscsi exporteren en op 3-4 clients gelijktijdig gebruiken?

+1 insightful..

een iScsi fs wordt verondersteld maar op 1 systeem tegelijk te mounten. (Wel tenzij je het over heel interresante cluster oplossingen hebt, maar dat heb je niet).

Dus een normale share aanmaken op freenas is wellicht handinger, en de dd alleen gebruiken als disktest (zfs comprimeerd null data toch? kan nu effe niet testen)

[Anoniem: 88711]

Gebruik zelf geen ZFS, maar goed..
Met het zfs set command kun je o.a. compressie aanzetten.

code:

zfs set compression=on pool-name/filesystem-name

Als het anders is verbeter me gerust.

Voor de shares kun je toch NFS of CIFS gebruiken.
Kijk hier eens naar.
Je kunt ook ZFS zelf sharen.