I'm in the same boat, about to divulge tonight.
Thanks for this submesa. And thanks for your other ZFS guide, I've been following it actively.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
FreeBSD ZFS NAS Web-GUI
- Thread starter sub.mesa
- Start date
- Status
Thanks for this submesa. And thanks for your other ZFS guide, I've been following it actively.
Don't know how I missed this, but I did. Haven't looked at it too closely, but a suggestion that's pretty relevant at this early stage:
Move system interactions to a wrapper script that interfaces the web side with the system, and provides some sanity checking and only the specific commands necessary. Then you can tighten down the sudo permissions required as well as have a bit of a safety net in case the web scripts go a bit wonky or someone finds an exploit. Yeah, this is a hobby type thing, but may as well do it right. Could also provide a slightly higher-level CLI to the storage system.
Also: Short tags? WTF?
Other than that, this looks really awesome and I'm going to keep my eye on it.
Move system interactions to a wrapper script that interfaces the web side with the system, and provides some sanity checking and only the specific commands necessary. Then you can tighten down the sudo permissions required as well as have a bit of a safety net in case the web scripts go a bit wonky or someone finds an exploit. Yeah, this is a hobby type thing, but may as well do it right. Could also provide a slightly higher-level CLI to the storage system.
Also: Short tags? WTF?
Other than that, this looks really awesome and I'm going to keep my eye on it.
wingfat
Weaksauce
- Joined
- May 13, 2010
- Messages
- 115
Up and running on a 5x2TB device with samba working...
Had to use Share-level security and chmod 777 /tank/share to enable windows 7 transfers.
Will post screen shots and more on monday.
Transfers max currently at 40MiB/s into share.... Is there an easy way to modify MTU?
Fantastic!
WF
Had to use Share-level security and chmod 777 /tank/share to enable windows 7 transfers.
Will post screen shots and more on monday.
Transfers max currently at 40MiB/s into share.... Is there an easy way to modify MTU?
Fantastic!
WF
Just a small update:
I'm currently looking at the non-web part of the project; the underlying FreeBSD system. Right now the binary pre-installed image that i ship becomes a writable filesystem once put on a flash media, and to install this one would need to use 'strange' tools under Windows. Ideally i want to release .iso versions; which everyone find easy to use and install.
So, initially, i thought about making three versions:
- script-only version for those who want to install FreeBSD themselves (powerusers)
- binary image with writable filetree (default freebsd)
- binary image with non-writable filetree (livecd like; does not save settings upon reboot)
Then i was thinking about some wilder idea:
- script-only version as above
- one combined livecd binary version that can use several binary system images.
This last option deserves some explanation. Essentially, you would download a .iso, burn it on cd, then boot it on your new NAS. Now after booting it selects a (compressed) system image file; the default one is on the CD and has everything pre-installed and setup properly. Any changes will be gone as you reboot. So pretty much a livecd which uses memory filesystem to be writable; but those changes will be gone after reboot.
Now comes the fun part: i can boot several disk images upon boot. So you could copy the default cd image to your ZFS pool and essentially install the operating system on ZFS; but use the CD to boot.
I still have to work this out, but the advantages are huge:
- i can release binary image updates that updates the system as well; right now i can only update the scripts part
- the CD-ROM/CompactFlash/USB stick would see no writes; it would act as livecd. Write once, read many.
- it allows you to go back to default/standard operating system image contained on CD, but make changes to freebsd and save those changes to your ZFS array instead
- you could have multiple system disk images; and choose in the web-interface which one to boot, before rebooting the system into the new selected image
If this is still somewhat vague, consider the CD to just boot the system, and the actual operating system to be installed to part of your zpool. Now if you ever lose that information; not too bad, all you would lose is samba share configuration basically. You could boot the default image again and reset your shares. You don't need anything from the Operating System really; unless you made changes yourself like emailserver, database, etc.
Lol i'm not sure if you guys can follow me; but i think this is a cool idea. It would be a good solid foundation for any changes like permissions, users and basically everything related to the underlying OS. I could release updates of binary images which contain newer versions of samba, or patches that fixes bugs, for example.
This is what i'm concentrating on now. Hope to release a .iso, but this could take awhile to master. Unknown territory for me.
I'm currently looking at the non-web part of the project; the underlying FreeBSD system. Right now the binary pre-installed image that i ship becomes a writable filesystem once put on a flash media, and to install this one would need to use 'strange' tools under Windows. Ideally i want to release .iso versions; which everyone find easy to use and install.
So, initially, i thought about making three versions:
- script-only version for those who want to install FreeBSD themselves (powerusers)
- binary image with writable filetree (default freebsd)
- binary image with non-writable filetree (livecd like; does not save settings upon reboot)
Then i was thinking about some wilder idea:
- script-only version as above
- one combined livecd binary version that can use several binary system images.
This last option deserves some explanation. Essentially, you would download a .iso, burn it on cd, then boot it on your new NAS. Now after booting it selects a (compressed) system image file; the default one is on the CD and has everything pre-installed and setup properly. Any changes will be gone as you reboot. So pretty much a livecd which uses memory filesystem to be writable; but those changes will be gone after reboot.
Now comes the fun part: i can boot several disk images upon boot. So you could copy the default cd image to your ZFS pool and essentially install the operating system on ZFS; but use the CD to boot.
I still have to work this out, but the advantages are huge:
- i can release binary image updates that updates the system as well; right now i can only update the scripts part
- the CD-ROM/CompactFlash/USB stick would see no writes; it would act as livecd. Write once, read many.
- it allows you to go back to default/standard operating system image contained on CD, but make changes to freebsd and save those changes to your ZFS array instead
- you could have multiple system disk images; and choose in the web-interface which one to boot, before rebooting the system into the new selected image
If this is still somewhat vague, consider the CD to just boot the system, and the actual operating system to be installed to part of your zpool. Now if you ever lose that information; not too bad, all you would lose is samba share configuration basically. You could boot the default image again and reset your shares. You don't need anything from the Operating System really; unless you made changes yourself like emailserver, database, etc.
Lol i'm not sure if you guys can follow me; but i think this is a cool idea. It would be a good solid foundation for any changes like permissions, users and basically everything related to the underlying OS. I could release updates of binary images which contain newer versions of samba, or patches that fixes bugs, for example.
This is what i'm concentrating on now. Hope to release a .iso, but this could take awhile to master. Unknown territory for me.
First of all, the script-only version will continue to exist. Preferably indeed as a port for easy installation. This allows you to do everything manually and just install the scripts on an existing system; potentially running a million other things other than NAS-related functions which my interface covers. So if i made a port, to install all you would need to do is:
This which would automatically install all dependencies like webserver, PHP and other stuff.
BUT! Aside from this i want to release binary pre-installed images, where everything comes pre-installed. The question is how to do that?
So how to do that? Well it's a bit technical all, but essentially what i want to do is a complex boot procedure:
ISO9660 filesystem on CDROM
1. boots from cd
2. loads the kernel and starts it
3. enters a 'first stage system' containing a mini-FreeBSD system disk image
4. in this stage, it could do a lot of things. it could read configuration file from your ZFS array, for example, or even mount the system disk located on a ZVOL. It could even display a menu to choose from, for example: A: Mesa FreeBSD 8.1 B: Mesa FreeBSD 9.0 beta C: custom install.
5. select binary image to work with, uncompress it (geom_uzip can directly read from compressed archives without decompressing on disk; it acts like software RAID driver but then for compression)
6. now make the selected/decompressed image the new root filesystem, essentially 'booting' that system disk image; which could be located anywhere like on your ZFS array.
7. the image boots and activates everything, becomes writable filesystem; either due to volatile memory backing or permanent storage on ZFS.
This is quite a sleek idea, i think! Why? Well, it would allow a lot of things:
There's a LOT of details that need to be looked at, and i'm just exploring my own limits of creativity as well. In the pre-boot environment (actually a minimized FreeBSD OS) i have a lot of freedom and can do basically anything. For example, plant my new pro-mesa trojan horse which i've working on lately. Just kidding guys.
Sorry for getting to such long posts. But they also serve to combine all my thoughts in an integral way; as i've been thinking a lot lately about different setups. I still have to work this out further and will spend a lot of time doing so, but the possibilities here are great!
Code:
cd /usr/ports/www/mesainterface
make install cleanBUT! Aside from this i want to release binary pre-installed images, where everything comes pre-installed. The question is how to do that?
- right now my binary image is writable meaning your CompactFlash/USB stick will wear out sometime and you would lose your 'system disk'; not cool!
- to remedy this, i need an image that is read-only and use a memory filesystem to make some parts writable, but after a reboot the contents of these will be gone and reset to the default setting again.
- to still allow saving changes (configuration in mesa interface, samba shares, other stuff) i need to store that somewhere
- options are: store somewhere on the system disk (say USB stick), store on the local ZFS storage (your big ZFS array surely has space for 200MB of system disk stuff), boot directly from your zpool, store on the network.
- i also want a way to update the freebsd system; i.e. you could go to the web-interface and see there is a binary update available - separate from the scripts' version - and update it, requiring a reboot to take effect
- also want to bundle some useful stuff on the CD image that i release, like MemTest86+ to test your memory, and HDDErase.exe+FreeDOS to perform Secure Erase on your SSDs. Though some versions of smartmontools also support this, meaning you would eventually be able to secure erase your SSDs using the web-interface.
So how to do that? Well it's a bit technical all, but essentially what i want to do is a complex boot procedure:
ISO9660 filesystem on CDROM
1. boots from cd
2. loads the kernel and starts it
3. enters a 'first stage system' containing a mini-FreeBSD system disk image
4. in this stage, it could do a lot of things. it could read configuration file from your ZFS array, for example, or even mount the system disk located on a ZVOL. It could even display a menu to choose from, for example: A: Mesa FreeBSD 8.1 B: Mesa FreeBSD 9.0 beta C: custom install.
5. select binary image to work with, uncompress it (geom_uzip can directly read from compressed archives without decompressing on disk; it acts like software RAID driver but then for compression)
6. now make the selected/decompressed image the new root filesystem, essentially 'booting' that system disk image; which could be located anywhere like on your ZFS array.
7. the image boots and activates everything, becomes writable filesystem; either due to volatile memory backing or permanent storage on ZFS.
This is quite a sleek idea, i think! Why? Well, it would allow a lot of things:
- allows you to boot from cd, usb or compactflash while not writing to it
- allows you to update your operating system with a single mouse click via the web interface (so cool!)
- allows you to snapshot your operating system, use several images you can choose from, and experiment with FreeBSD while always able to go back to the default image
- allows you to store the configuration on your ZFS array; meaning the USB/CompactFlash/CD itself does not store any personal information.
- in theory, i could also setup the system so that you could boot directly from any (doesn't matter which) disk part of your ZFS array, so you would boot from a software RAID6 for example, without use of USB/CF/CDROM. Many people think that's not possible, but it is! Note that OpenSolaris only supports booting from mirrors or single disk volumes; not raidz's.
- best of all: it still allows a full fledged FreeBSD install, either ZFS or UFS based with full write access. That means you can have database stuff and other customizations done outside my interface (via SSH for example) - and allow you to backup and maintain those conveniently.
There's a LOT of details that need to be looked at, and i'm just exploring my own limits of creativity as well. In the pre-boot environment (actually a minimized FreeBSD OS) i have a lot of freedom and can do basically anything. For example, plant my new pro-mesa trojan horse which i've working on lately. Just kidding guys.
Sorry for getting to such long posts. But they also serve to combine all my thoughts in an integral way; as i've been thinking a lot lately about different setups. I still have to work this out further and will spend a lot of time doing so, but the possibilities here are great!
Look at NanoBSD for building embedded stuff. pfSense recently migrated to this (from a more traditional read-only setup like you're proposing) and it works very well. Much better than trying to roll your own solution to the flash memory problem, all of your issues are already dealt with, and it's pretty easy to set up and consistent between releases from a development standpoint.
Yeah those are the rough edges; will be gone next release though. Note that default Samba config is used; you may use tuning parameters in smb.conf. You can add them manually and the interface would leave them alone. The samba configuration file is located:
ee /usr/local/etc/smb.conf
ifconfig em0 mtu 9000
em0 = intel adapter; your name could be different. Look in Network tab in web-interface or 'ifconfig'. Later MTU will be configurable via the interface instead. Note: this requires MTU support in your switch and other PCs on the LAN to use the same MTU setting. i.e. do MTU 7000/9000 for all pc's. Choose the highest value supported on all hardware/systems. Thus if all systems do 9000 MTU but only one is limited to 7000, then you use 7000 for all PCs.
Yes i looked at NanoBSD; very nice project indeed! But it doesn't use the new tmpfs which is great as it uses dynamic allocation; it grows as you store more files and shrinks automatically again; thus the only limit is your RAM. NanoBSD uses fixed-size partitions; which isn't terrible but not as sleek. Ideally i would like a platform with the fewest limitations. NanoBSD would require me to spend alot of time on their configuration file; where most of the work is done. I think NanoBSD is great for its purpose but perhaps i can find something better?
But perhaps the biggest reason i didn't look to far into NanoBSD for now, is that this is also an opportunity for me to learn FreeBSD better and explore all the possibilities and be creative; so far i had numerous ideas which i think could be great from a user standpoint.
For example, just for the funs of it, wouldn't it be great marketing for my new opensource 'storage platform'? Only needs a cd, once installed with a few mouseclicks it boots off your physical disks part of RAID-Z2 or even RAID-Z3 in the future. At least i could prove that it actually works; requiring no special BIOS setup. For the BIOS it would just be alot of single disks, and it would boot off a random one (well likely first disk on first controller - but it wouldn't matter which), and still allow you to upgrade the operating system with a single mouse click in the web-interface. Even would allow a hundred different Operating Systems to choose from, if you so desire, all located on your raidz pool. Isn't that.. WOW?
It wouldn't only be useful to casual/novice users (at least to UNIX) - it could also be great for more experienced users who like to adapt alot to their setup and maintain different binary images; the default 'factory shipped' mesa image; some experimental/beta versions, and some versions you adapted/modified yourself. You would still get a full fledged FreeBSD system with all bells and whistles and a fully writable (permanent) system. Thus; no limitations. I never liked those.
Or do you think i'm overburdening myself?
I already realized this project is only getting bigger the more time i spend on it.
Hey guys!
During the time Kyle spanked his server trying to get it up - i've been working on my Mesa project.
I've not touched the scripts much; instead i have concentrated on making LiveCDs so i can give you guys .iso's to try. Better yet, i've automated my build process and can dish out new .iso's built from scratch with a single command now.
I've worked long on this - but it was time well spent! I now have a FreeBSD system running in tmpfs memory; meaning you can remove the cdrom after it has completed booting and wouldn't be needed again. The downside is about 400MB extra memory usage and added boot time, but there are plenty of solutions to that in the future.
Right now i want to get my existing mesa release running in a LiveCD; and i'm very close to doing it. ;-)
Stay tuned.
During the time Kyle spanked his server trying to get it up - i've been working on my Mesa project.
I've not touched the scripts much; instead i have concentrated on making LiveCDs so i can give you guys .iso's to try. Better yet, i've automated my build process and can dish out new .iso's built from scratch with a single command now.
I've worked long on this - but it was time well spent! I now have a FreeBSD system running in tmpfs memory; meaning you can remove the cdrom after it has completed booting and wouldn't be needed again. The downside is about 400MB extra memory usage and added boot time, but there are plenty of solutions to that in the future.
Right now i want to get my existing mesa release running in a LiveCD; and i'm very close to doing it. ;-)
Stay tuned.
wingfat
Weaksauce
- Joined
- May 13, 2010
- Messages
- 115
Sub...
What is you recommendation for 2TB consumer drives?. I made a huge mistake purchasing 15 WD 2TB EARS drives. ZFS does not like them. My SAMSUNG EcoGreen F3 HD203WI device (5x2TB) seems to be fine. I have read they can generate many smart errors quickly however.
Is there a 2TB consumer drive that can be used reliably? I know the "Black" WD 2TB will perform well but it's double the price. In your vast roamings around the web what seems to fit the bill if anything?
Thanks....
N.B. Still have the startup problem.. I'll check out your new iso when available.
wf
What is you recommendation for 2TB consumer drives?. I made a huge mistake purchasing 15 WD 2TB EARS drives. ZFS does not like them. My SAMSUNG EcoGreen F3 HD203WI device (5x2TB) seems to be fine. I have read they can generate many smart errors quickly however.
Is there a 2TB consumer drive that can be used reliably? I know the "Black" WD 2TB will perform well but it's double the price. In your vast roamings around the web what seems to fit the bill if anything?
Thanks....
N.B. Still have the startup problem.. I'll check out your new iso when available.
wf
Hm well i haven't had a chance to test EARS and ZFS myself. Did the geom_nop trick by pitting .nop providers on top of the disks help you by any degree? On what OS did you test EARS with ZFS? Did you use partitions on the disks?
If the geom_nop improves anything, i could apply them everytime at boot automatically for disks identified with "EARS" product code. If that would be helpful? It would cause the EARS drives to identify themselves with 4096 byte or 4KiB sector size to ZFS.
The normal WD Green WD15EADS (512 byte sectors) would do; 5400rpm though but i actually prefer that for storing large files. As you can combine SSDs and HDDs with ZFS the rpm part becomes even less important; as you can deal most random accesses with SSDs instead in the right setup. Best of all; you can just start with HDDs and add the SSDs later, when the next generation of 6Gbps NAND controller SSDs come out around Christmas.
Well that problem will surely be gone with the ISO, as it uses a totally different boot routine. So yeah try the ISO when it's available, i think tomorrow already.
I already got my Mesa interface working straight off the cd, after booting you can even remove the cd; it won't be used anymore. After booting the entire system will run in RAM; meaning you need at least 1GB RAM to test this reasonably; 500MB for the system and 500MB for ZFS as a bare minimum.
Before i release 0.1.4 (which has little web-script changes), i need to:
- fix permission issues with Samba/NFS
- use better default smb.conf Samba configuration file
- make sure the livecd's initial boot environment is working properly
Not too much, i expect to release .iso tomorrow.
New Release: 0.1.4-LiveCD
download url: http://submesa.com/files/Mesa-0.1.4-livecd.tbz (edit: link working now!)
Fresh from the oven! 0.1.4 LiveCD .iso image is ready for testing! Please ensure not to touch any real data with it; only use it to test, particularly Samba. In the default configuration you would be able to go to \\<IP> and see two shares: mesa and tmpfs. The latter is writable and uses your RAM as storage so you can test network performance without having the disks slow you down. It reads about 1GB/s and 3GB/s write inside Virtualbox for me, so plenty of performance here!
There is still only permission issue, when you create ZFS arrays the Samba permissions won't allow you to access it. You would need to manually change permissions like "chmod -R 777 /mountpoint" inside the root command line. This will be fixed in the next release (0.1.5).
Let me know how it fares.
download url: http://submesa.com/files/Mesa-0.1.4-livecd.tbz (edit: link working now!)
Fresh from the oven! 0.1.4 LiveCD .iso image is ready for testing! Please ensure not to touch any real data with it; only use it to test, particularly Samba. In the default configuration you would be able to go to \\<IP> and see two shares: mesa and tmpfs. The latter is writable and uses your RAM as storage so you can test network performance without having the disks slow you down. It reads about 1GB/s and 3GB/s write inside Virtualbox for me, so plenty of performance here!
There is still only permission issue, when you create ZFS arrays the Samba permissions won't allow you to access it. You would need to manually change permissions like "chmod -R 777 /mountpoint" inside the root command line. This will be fixed in the next release (0.1.5).
Let me know how it fares.
Last edited:
pipingfiend
n00b
- Joined
- Apr 20, 2010
- Messages
- 5
When do we expect this release to be stable to start loading data? Just tossing up between freenas and this as it does what i want.
it seems this little project has started at simply adding a web control panel for some NAS functions, to making a GUI for freebsd itself almost....? i think that would make that easier for a lot of people. even if there was only a GUI or something to get your initial config setup, that would be good.
with thumb drives being $3 per GB or less, once i got the file system how i like it, i would have no problem just copying the whole system flash drive to another just in case that happened. i know that would mean some downtime when the thing actually died, but then you just throw it in the trash, plug the other in and reboot. you could probably even set it up to have a hot spare via USB.
BACK FROM A TRIP - no i am not gone.
If you would have a fallback solution in place or do not get into trouble when you (temporarily) lose access to the data, yes you could use it from 0.2.x onwards. If this sounds unreliable to you, consider that i am quite paranoid, especially about data storage. Actually i think storing data is pretty scary, especially if it's important. Lots of people are naive in the assumption it will all continue to work and be available in the future like it was in the past and current.
But if i had to choose between Hardware RAID5+NTFS or my Mesa Webinterface in current state to exclusively store my most important files, i would opt for the latter choice, of course. But you have to understand labeling something 'ready for use' bears a lot of responsibility; any i want to avoid cases where a mistake on my part kills a user's important data.
You should also know that despite my trust in ZFS, i keep a full backup of all my data and third offsite for my business ('simply cant afford to lose') data. Backups remain a primary means of protecting your data against permanent dataloss; they are superior to mostly any other solution. But it's always best if you combine the three key elements for secure storage: an advanced checksumming filesystem, a write-safe RAID-engine and a properly implemented backup plan.
Oh, you asked when!
Well i had 0.2.x planned for August; this month. But you should consider that to be a rough schedule only; depending on how things go it could go pretty quick or take longer.
I would also require much more feedback as soon as i release alpha/beta's; after i received enough feedback i would release 0.2.x probably; and from that point on develop in the experimental branch and maintain bugfixes in the stable branch. I want people to choose between something more tested but less frequently updated (like "LTS" linux releases) and fast updating but much less tested releases.
0.2.0 is my targeted semi-stable 'early adopter' release. That means: it should work, but is still not widely tested and unknown issues may still threaten your data. More likely, it would mean a bug disrupts the normal operation of your NAS but does not actually harm data; but my interface surely has the potential to harm data already.
If you would have a fallback solution in place or do not get into trouble when you (temporarily) lose access to the data, yes you could use it from 0.2.x onwards. If this sounds unreliable to you, consider that i am quite paranoid, especially about data storage. Actually i think storing data is pretty scary, especially if it's important. Lots of people are naive in the assumption it will all continue to work and be available in the future like it was in the past and current.
But if i had to choose between Hardware RAID5+NTFS or my Mesa Webinterface in current state to exclusively store my most important files, i would opt for the latter choice, of course. But you have to understand labeling something 'ready for use' bears a lot of responsibility; any i want to avoid cases where a mistake on my part kills a user's important data.
You should also know that despite my trust in ZFS, i keep a full backup of all my data and third offsite for my business ('simply cant afford to lose') data. Backups remain a primary means of protecting your data against permanent dataloss; they are superior to mostly any other solution. But it's always best if you combine the three key elements for secure storage: an advanced checksumming filesystem, a write-safe RAID-engine and a properly implemented backup plan.
Oh, you asked when!
Well i had 0.2.x planned for August; this month. But you should consider that to be a rough schedule only; depending on how things go it could go pretty quick or take longer.
I would also require much more feedback as soon as i release alpha/beta's; after i received enough feedback i would release 0.2.x probably; and from that point on develop in the experimental branch and maintain bugfixes in the stable branch. I want people to choose between something more tested but less frequently updated (like "LTS" linux releases) and fast updating but much less tested releases.
Not a GUI for FreeBSD; though it will have things like Firewall and other stuff. It will be targeting NAS-related functions primarily. A full FreeBSD GUI would be too large a project for me to implement while keeping the Open Source model, which i know you all want. But i have to do this in my spare time; so i have to focus my efforts towards something viable.
However, the project did expand from simply being some .php scripts to something like a FreeBSD distribution, much like FreeNAS ships its modified FreeBSD releases. Unlike FreeNAS i haven't stripped any part of FreeBSD yet though. And i want to keep the option of just using the .php scripts.
But this has the consequence that i also have to spend time on adapting the FreeBSD system towards my goals. But i really enjoyed spending this time, to learn more about FreeBSD.
Yes, true. But you would lose any changes to Samba-shares and Web-interface preferences since your last backup. This could be done better! By storing all configuration data on your array instead - you could just have a USB or CDROM that doesn't need to be written to. Only if you have to change/update the kernel.
I haven't had a chance to test this yet. I think it should work, but requires BIOS support to boot from USB CD-ROM instead. It could be, however, that your USB stick is detected as USB-HDD ('mass storage device') and that the ISO9660 ("CDROM") filesystem does not work in that case.
Does the CD-R option work for you, though?
Yes the CDR will work on the test rig, however the final system(s) will not have an optical drive. I have had minimal luck in getting a ISO9660 to boot from a usb key, the best I can get is by using a tool over on the Corsair forums called The Ultimate Bootable USB Flash Drive Tool. But FreeBSD will eventually fail during startup with the following:
Geom: da0: partition 1 does not end on a track boundary.
Enter full pathname of shell or RETURN for /bin/sh:
Anyone have a better idea? I really would like to keep the OS on a pen drive, and spending another 100$ on 2 slim dvd drives just to boot sucks
Sub.mesa: any chance you can release the livecd's in a format thats friendly for usb drives?
Geom: da0: partition 1 does not end on a track boundary.
Enter full pathname of shell or RETURN for /bin/sh:
Anyone have a better idea? I really would like to keep the OS on a pen drive, and spending another 100$ on 2 slim dvd drives just to boot sucks
Sub.mesa: any chance you can release the livecd's in a format thats friendly for usb drives?
I'm getting ready to dive into this..
I'm curious though, is it possible to trigger some sort of alarm if the pool becomes degraded?
I wonder how difficult it would be to build an interface with some led's for the disks.. not that I have to have that. but the alarm would be nice.
I'm curious though, is it possible to trigger some sort of alarm if the pool becomes degraded?
I wonder how difficult it would be to build an interface with some led's for the disks.. not that I have to have that. but the alarm would be nice.
@all: not much news; had some trouble adapting my build scripts when i moved over to my quadcore box for faster compiling; also also ran into some tmpfs issues. Have to resolve those before i can do any new releases.
update: appear to be having my build script issues under control; i now can build LiveCDs based upon FreeBSD 9.0 also; featuring ZFS pool version 15, just like Solaris.
@nexxium:
Have you tried the binary release yet? That's the one primarily meant for USB media. It is much less experimental than the LiveCD, which uses tmpfs. It's simply a pre-installed pre-configured FreeBSD on USB-stick that should be bootable, though some users like wingfat on this forum had issues booting it.
You may also look at some of Wingfat's earlier posts regarding an alternative free tool for Windows to write my image with; though to rule anything out, writing the binary image to USB-stick using the Ubuntu method, as described on my website, is still the preferred method. The binary image is not yet updated to FreeBSD 8.1-final, however. But you can test if it works, and be sure to do an update of the web-interface once installed; Extra->Update.
@tojoski:
Features like email notification on degraded arrays are planned. Also planned is a way to select disks to do I/O so you can identify the disks on LEDs. If a disk failed completely, only that disks LED won't light up. Also, you assign a chosen name for each disk that will identify it from then on; this is implemented already as you format physical disks on the Disks page.
update: appear to be having my build script issues under control; i now can build LiveCDs based upon FreeBSD 9.0 also; featuring ZFS pool version 15, just like Solaris.
@nexxium:
Have you tried the binary release yet? That's the one primarily meant for USB media. It is much less experimental than the LiveCD, which uses tmpfs. It's simply a pre-installed pre-configured FreeBSD on USB-stick that should be bootable, though some users like wingfat on this forum had issues booting it.
You may also look at some of Wingfat's earlier posts regarding an alternative free tool for Windows to write my image with; though to rule anything out, writing the binary image to USB-stick using the Ubuntu method, as described on my website, is still the preferred method. The binary image is not yet updated to FreeBSD 8.1-final, however. But you can test if it works, and be sure to do an update of the web-interface once installed; Extra->Update.
@tojoski:
Features like email notification on degraded arrays are planned. Also planned is a way to select disks to do I/O so you can identify the disks on LEDs. If a disk failed completely, only that disks LED won't light up. Also, you assign a chosen name for each disk that will identify it from then on; this is implemented already as you format physical disks on the Disks page.
Last edited:
Spent a lot of time doing boring stuff, but made extensive progress on getting the binary/livecd images on track and sharing a combined build environment. Now i can build everything with my scripts; and it works! Some highlights:
- permission issue fixed in upcoming 0.1.5 release (shares are writable)
- hopefully permanent fix for binary image boot issues ("mountroot" prompt) due to using GPT boot
- first binary image for USB stick bootable since new build architecture
- binary image now uses tmpfs just like LiveCD does
- currently working on mounting USB in such a way that system changes will be preserved
- also working on new website
- still need a proper NAME for my project!
So not many source changes but these things are important! After i figured this all out, you will be able to use both the LiveCD and USB binary image and have your changes saved across reboots:
- the USB binary image will save this on USB instead, and copy from/to tmpfs upon each boot; this also makes it possible to change loader.conf tunable options which you can't on the LiveCD without burning a new CD.
- the LiveCD can't be written to, but it can use an existing pool with some data reserved to my project to store your samba configuration and other stuff. So this is the idea: you 'install' mesa via the web-interface to one of your zpools and it will be used to save system settings like Samba shares and the web-interface configuration file. So even with a LiveCD you could be using it 'for real' without the true volatile nature of memory filesystems.
Benefits:
- avoids you messing up FreeBSD; simply reboot and it will be fresh again as i released it. Counts for both binary and LiveCD distributions.
- allows samba and other system settings to work across reboots (LiveCD requires a user-action here; chosing a zpool to install Mesa to; it will only take a few megs at most and should only require a few mouseclicks upon initial installation and setup.
- no writing to either LiveCD or USB image required. The USB stick only received writes as you shutdown/reboot or save configuration manually.
- removing either USB stick or LiveCD when the system is running is perfectly fine; it's not required for the Operating System any longer since it lives on memory filesystem.
- you could easily download new system disk images via the web and update your system (for example: new packages/features/tuning/whatever); LiveCD would require to be re-downloaded if the kernel changes though
- my build architecture is now portable (works on other systems) and can build LiveCDs based on FreeBSD 9-CURRENT as well, which sports ZFS pool version 15 and many important fixes. But it's release is still at least half a year away.
I'm also working at improving my website for bug reports and other stuff. I experimented a bit with CSS3 stuff. That brings us to what to do with IE. Are there many of you that use IE and if so what version? I can't imagine me supporting IE6 anymore; but IE7 and IE8 still have a long road to go; even though IE9 is just behind the corner. Ideally i would use CSS3 options which are more pleasing to the eye and just show less nice pages (but still fully functional) on IE. So it becomes 'optional' in that sense that it improves visual aspects but not affect usability. Any thoughts here?
- permission issue fixed in upcoming 0.1.5 release (shares are writable)
- hopefully permanent fix for binary image boot issues ("mountroot" prompt) due to using GPT boot
- first binary image for USB stick bootable since new build architecture
- binary image now uses tmpfs just like LiveCD does
- currently working on mounting USB in such a way that system changes will be preserved
- also working on new website
- still need a proper NAME for my project!
So not many source changes but these things are important! After i figured this all out, you will be able to use both the LiveCD and USB binary image and have your changes saved across reboots:
- the USB binary image will save this on USB instead, and copy from/to tmpfs upon each boot; this also makes it possible to change loader.conf tunable options which you can't on the LiveCD without burning a new CD.
- the LiveCD can't be written to, but it can use an existing pool with some data reserved to my project to store your samba configuration and other stuff. So this is the idea: you 'install' mesa via the web-interface to one of your zpools and it will be used to save system settings like Samba shares and the web-interface configuration file. So even with a LiveCD you could be using it 'for real' without the true volatile nature of memory filesystems.
Benefits:
- avoids you messing up FreeBSD; simply reboot and it will be fresh again as i released it. Counts for both binary and LiveCD distributions.
- allows samba and other system settings to work across reboots (LiveCD requires a user-action here; chosing a zpool to install Mesa to; it will only take a few megs at most and should only require a few mouseclicks upon initial installation and setup.
- no writing to either LiveCD or USB image required. The USB stick only received writes as you shutdown/reboot or save configuration manually.
- removing either USB stick or LiveCD when the system is running is perfectly fine; it's not required for the Operating System any longer since it lives on memory filesystem.
- you could easily download new system disk images via the web and update your system (for example: new packages/features/tuning/whatever); LiveCD would require to be re-downloaded if the kernel changes though
- my build architecture is now portable (works on other systems) and can build LiveCDs based on FreeBSD 9-CURRENT as well, which sports ZFS pool version 15 and many important fixes. But it's release is still at least half a year away.
I'm also working at improving my website for bug reports and other stuff. I experimented a bit with CSS3 stuff. That brings us to what to do with IE. Are there many of you that use IE and if so what version? I can't imagine me supporting IE6 anymore; but IE7 and IE8 still have a long road to go; even though IE9 is just behind the corner. Ideally i would use CSS3 options which are more pleasing to the eye and just show less nice pages (but still fully functional) on IE. So it becomes 'optional' in that sense that it improves visual aspects but not affect usability. Any thoughts here?
wingfat
Weaksauce
- Joined
- May 13, 2010
- Messages
- 115
I now use Chrome 99% of the time and can't imagine switching to IE unless you make me!
WF
WF
It appears the rounded corners and gradient CSS3 stuff works as of Firefox 3.6; so i think Chrome and Opera and Safari will do well too; though i'm too lazy to look this up.
Either way, i could make a "Webpage standard" preference that lets you select CSS1 (IE6?), CSS2 (IE7/8) or CSS3 (modern engines) standard adherence. I'm not keen on making any browser specific tuning or markup, but CSS3 is not finalized yet so will need -moz- prefixes and such.
Either way, i could make a "Webpage standard" preference that lets you select CSS1 (IE6?), CSS2 (IE7/8) or CSS3 (modern engines) standard adherence. I'm not keen on making any browser specific tuning or markup, but CSS3 is not finalized yet so will need -moz- prefixes and such.
Alright but IE7 and IE8 are still 'major' browsers; and i don't think they support these CSS3 attributes. Perhaps IE9. But if i can enable it without breaking these browsers, that would be the easy route and just benefit users with modern browsers with more pleasing graphics.
I've had a huge break with storing and retrieving saved settings on USB media; i could be releasing 0.1.5 USB+LiveCD media pretty soon. Samba configuration, web-interface preferences and ZFS zpool cache file will be preserved across reboots. It works like this:
1. Once you boot from USB, your settings on the USB are copied to the operating system
2. The USB media is then unmounted and can be removed from the running system
3. Once you shutdown, the system checks if your USB stick is inserted
4. If it is, it stores your settings on there; so they get preserved next boot. If its not; it just skips this and it will use the existing version on the USB stick next boot.
Thus the USB stick would only see some minor writes upon shutdown; and alot of reads when booting. Ideal for NAND flash media!
I'm also working on a way to format and write a USB stick with the binary image from within the livecd; so it wouldn't be a hassle to write a USB stick under Windows anymore. Simply burn the livecd, boot on any system or virtualbox and click the install button to install to your pendrive; i love the simplicity!
Anyone who test my upcoming 0.1.5 release? Preferably both USB and LiveCD media.
Things i need to know are: any issues with booting resolved? Are created ZFS pools are still visible after reboot (i.e. do not need to be imported)? The USB stick should save these by copying zpool.cache file, but LiveCD has no solution yet for changing configuration.
I'm quite confident with my development methods now; the hard parts are over i think. Now i can focus more on my web-interface scripts and do more releases! I hope to release a stable version end this month.
I've had a huge break with storing and retrieving saved settings on USB media; i could be releasing 0.1.5 USB+LiveCD media pretty soon. Samba configuration, web-interface preferences and ZFS zpool cache file will be preserved across reboots. It works like this:
1. Once you boot from USB, your settings on the USB are copied to the operating system
2. The USB media is then unmounted and can be removed from the running system
3. Once you shutdown, the system checks if your USB stick is inserted
4. If it is, it stores your settings on there; so they get preserved next boot. If its not; it just skips this and it will use the existing version on the USB stick next boot.
Thus the USB stick would only see some minor writes upon shutdown; and alot of reads when booting. Ideal for NAND flash media!
I'm also working on a way to format and write a USB stick with the binary image from within the livecd; so it wouldn't be a hassle to write a USB stick under Windows anymore. Simply burn the livecd, boot on any system or virtualbox and click the install button to install to your pendrive; i love the simplicity!
Anyone who test my upcoming 0.1.5 release? Preferably both USB and LiveCD media.
Things i need to know are: any issues with booting resolved? Are created ZFS pools are still visible after reboot (i.e. do not need to be imported)? The USB stick should save these by copying zpool.cache file, but LiveCD has no solution yet for changing configuration.
I'm quite confident with my development methods now; the hard parts are over i think. Now i can focus more on my web-interface scripts and do more releases! I hope to release a stable version end this month.
I will be happy to test another release, only USB though, dont have a optical drive connected to the server.
Really looking forward to the next releases
One quick question, will we be able to install new/different programs than the ones you allready install in the image? Say MySQL/Apache for example?
Really looking forward to the next releases
One quick question, will we be able to install new/different programs than the ones you allready install in the image? Say MySQL/Apache for example?
What method of writing usb stick works for you?
Regarding your question, you can install everything you want, but the real question is whether those changes will be preserved upon reboot. Right now they don't. Unlike the current 0.1.1 binary image, the 0.1.5 binary image will also be based on tmpfs and thus lose all settings/changes upon reboot.
Except of course, those who are restored upon boot. And that's where the solution lies: you could have a user-modified script on your USB stick that installs packages and copies over (modified) config files. Upon shutdown, they are saved back to USB again. The same solution i use with Samba/web config and zpool.cache files. And it works.
So i could make something in the web interface allowing you to edit your install script to install whatever you need, and preserve its settings.
The alternative would be to install FreeBSD manually and use my script-releases only; installing everything yourself.
Regarding your question, you can install everything you want, but the real question is whether those changes will be preserved upon reboot. Right now they don't. Unlike the current 0.1.1 binary image, the 0.1.5 binary image will also be based on tmpfs and thus lose all settings/changes upon reboot.
Except of course, those who are restored upon boot. And that's where the solution lies: you could have a user-modified script on your USB stick that installs packages and copies over (modified) config files. Upon shutdown, they are saved back to USB again. The same solution i use with Samba/web config and zpool.cache files. And it works.
So i could make something in the web interface allowing you to edit your install script to install whatever you need, and preserve its settings.
The alternative would be to install FreeBSD manually and use my script-releases only; installing everything yourself.
I used winimager i think its called, worked perfect.
If you could make it so that we can install packages on the system, and they're then restored on reboot, that would be perfect.
Installing everything myself was originally my plan. But by using your usb image, and making freebsd run in memory instead, i wont have to use 2 HD's as mirrors for boot. Instead, they can be used for ZFS storage
If you could make it so that we can install packages on the system, and they're then restored on reboot, that would be perfect.
Installing everything myself was originally my plan. But by using your usb image, and making freebsd run in memory instead, i wont have to use 2 HD's as mirrors for boot. Instead, they can be used for ZFS storage
Okay i made a first effort of preserving manually installed stuff on USB. But you would need to modify your modscript.sh file located in mod directory on USB stick. I plan on allowing this via the web-interface.
It could be as simple as 'uncommenting' (i.e. removing # characters) a few lines to get MySQL or another service working, and you could add basically everything. Only things stored in this script file will 'survive' a reboot; all the others will be washed away into nothingness; so be sure to test this properly if you ever going to deploy it for real. Of course, you can point your MySQL data directory to a location on a (permanent) ZFS filesystem, so only the configuration script and package would need to be installed using the script.
And yeah not requiring a system disk is great since it indeed saves you from alot of hassle. But it has drawbacks too; you get 500MB less RAM since it's dedicated to the system disk. It is capable of being swapped to disk if you ever activate a swap device (or file on ZFS filesystem). tmpfs is incredibly fast though; any I/O done is like 50% of raw memory speed; which is very good! It is most apparent when dealing with lots of small files, which tend to be incredibly slow on HDDs. It's like a supercharged SSD on steroids, so to speak.
It could be as simple as 'uncommenting' (i.e. removing # characters) a few lines to get MySQL or another service working, and you could add basically everything. Only things stored in this script file will 'survive' a reboot; all the others will be washed away into nothingness; so be sure to test this properly if you ever going to deploy it for real. Of course, you can point your MySQL data directory to a location on a (permanent) ZFS filesystem, so only the configuration script and package would need to be installed using the script.
And yeah not requiring a system disk is great since it indeed saves you from alot of hassle. But it has drawbacks too; you get 500MB less RAM since it's dedicated to the system disk. It is capable of being swapped to disk if you ever activate a swap device (or file on ZFS filesystem). tmpfs is incredibly fast though; any I/O done is like 50% of raw memory speed; which is very good! It is most apparent when dealing with lots of small files, which tend to be incredibly slow on HDDs. It's like a supercharged SSD on steroids, so to speak.
Well, 500mb of ram is really nothing these days, currently im testing your image on a system with 4 gig, the final build will have 8-16 gigs, depending on price. Even ZFS is memory hungry, but since this is just as home build, i think even 7,5 gigs should be enough
Yes 8GB RAM with 0.5 dedicated to system would be great! De-duplication would want more RAM (16/32GB) or a fast SSD. But i don't think de-duplication is so sexy if the benefits are below 25% space saved. Besides its not stable at the moment.
About the modifying stuff: i now implemented a simple mod script architecture, and ship with one example: smartmontools (SMART monitoring of your disks). I think i might be releasing this soon.
About the modifying stuff: i now implemented a simple mod script architecture, and ship with one example: smartmontools (SMART monitoring of your disks). I think i might be releasing this soon.
New Release: 0.1.5-LiveCD/Binary
Download
LiveCD: http://submesa.com/files/Mesa-0.1.5-livecd.iso
USB (Binary): http://submesa.com/mesa (and follow instructions)
0.1.5 Adds many changes, though most are invisible to the user. Most important changes are:
Most things should work out of the box. The USB image has more options like saving zpool cache file (automatically imports your arrays upon boot) and Samba configuration file and web-interface preferences. The LiveCD still lacks such a mechanism, and as such is truely volatile; each reboot would wipe away any changes you make. Except to ZFS filesystems on physical disks, of course.
Let me know how it fares.
Download
LiveCD: http://submesa.com/files/Mesa-0.1.5-livecd.iso
USB (Binary): http://submesa.com/mesa (and follow instructions)
0.1.5 Adds many changes, though most are invisible to the user. Most important changes are:
Most things should work out of the box. The USB image has more options like saving zpool cache file (automatically imports your arrays upon boot) and Samba configuration file and web-interface preferences. The LiveCD still lacks such a mechanism, and as such is truely volatile; each reboot would wipe away any changes you make. Except to ZFS filesystems on physical disks, of course.
Let me know how it fares.
wingfat
Weaksauce
- Joined
- May 13, 2010
- Messages
- 115
Testing 0.15 via USB... Mesa has come a long way in a very short time.. The boot / mount problem has been fixed.. My zfs file systems made it thru a reboot. I'm still playing but file transfer speed is very good. When do you think writing the system to a zfs or cache disk will be possible? I'm stuck at 4gigs for this server and it would be nice to reclaim the 500mb of ram.
Time to start the "name mesa" contest!
Sub...
Tested functions so far: Search for hidden pools...OK found "newer version" ZFS system created by Opensolaris 134dev
Search for deleted pools...OK found above pool after I destroyed it
Create new zpool....OK created zpool tank with 4x1TB drives raidz (not comfortable with current description of parity levels "Raid5 etc" - ) May want to add Raidz, Raidz2 etc to avoid confusion?)
Expand pool....OK Expanded tank with 4x2TB drives raidz
Created new filesystem...OK Created tank/backup and enabled nfs and samba... access-able from win7 and Opensolaris systems
Benchmark Drives..OK Disk bandwidth monitor...OK
Waiting for enable Cache drive, iSCSI
I have a question about Zvol.. I'm not sure what it's used for or what to do with it? I've created my filesystem and I thought these WERE zvol's ?
First name that system entry: "Simple ZFS" or "Simple ZFS Storage"
Jeff
Time to start the "name mesa" contest!
Sub...
Tested functions so far: Search for hidden pools...OK found "newer version" ZFS system created by Opensolaris 134dev
Search for deleted pools...OK found above pool after I destroyed it
Create new zpool....OK created zpool tank with 4x1TB drives raidz (not comfortable with current description of parity levels "Raid5 etc" - ) May want to add Raidz, Raidz2 etc to avoid confusion?)
Expand pool....OK Expanded tank with 4x2TB drives raidz
Created new filesystem...OK Created tank/backup and enabled nfs and samba... access-able from win7 and Opensolaris systems
Benchmark Drives..OK Disk bandwidth monitor...OK
Waiting for enable Cache drive, iSCSI
I have a question about Zvol.. I'm not sure what it's used for or what to do with it? I've created my filesystem and I thought these WERE zvol's ?
First name that system entry: "Simple ZFS" or "Simple ZFS Storage"
Jeff
Last edited:
Hey Jeff; thanks for testing!
Nice to know it still works. And yes i might change the "RAID" description. But to make things even more complicated; RAID-Z really is not a RAID spec at all; ZFS does not support "RAID". RAID is an on-disk specification which allows you to use multiple drives to reconstruct a virtual single device. This 'virtual harddisk' is then fed to the (NTFS?) filesystem. But with RAID-Z, no ordinary RAID engine could ever reproduce the way ZFS uses it; it wouldn't be possible to write everything to a larger single disk, such as is possible with any 'real' RAID scheme.
The current RAID scheme is flawed and only lives on due to it being a recognizable term for using multiple disks to store the same data. RAID-Z might only make that more complicated. However, for the user, it closely mimics the characteristics of RAID5 (one disk can completely fail but no more; space = n-1 or n-2 for raidz2). So i will have to think about correct terminology.
About ZVOLs: these are little virtual harddrives themselves. So imagine you have a 4GB ZVOL on your 2000GB ZFS filesystem; it would start to consume 4GB of space right away. Now this ZVOL acts just like a harddrive for most intents and purposes. You could format it with UFS, even create a new ZFS pool on this ZVOL. It's like a harddrive whose actual storage is mapped to a file on ZFS; this special file type is called a ZVOL.
ZVOLs can be useful for many things, but primarily it's iSCSI which uses these. iSCSI is a SAN protocol so the underlying filesystem would be different. Windows booting with iSCSI could store its NTFS filesystem on the ZVOL; which is actually stored on ZFS. Since ZFS is the underlying storage device, things like checksums, de-duplication and compression all work on the ZVOL even though NTFS may not support these features.
NAS protocols like Samba, NFS and FTP, however, use the server-side filesystem to locate and process files. So with these protocols you would not be using ZVOLs but just ordinary files on ZFS filesystem.
Edit: to help understanding the place of ZVOLs, let me list all of them:
disk: physical disk fed to ZFS; can be a partition, a labeled disk, or whole disk
vdev: an array like RAID-Z, mirror or single device, with one or more disks attached to it
pool: a combined volume which has at least one vdev. If it contains multiple vdevs (arrays) then all free space is combined as a whole and available to any location on the pool. Thus a pool is a collection of vdevs.
zvol: an optional 'virtual disk' that behaves just like a block-level device (harddrive) and can be used to store basically anything; including other filesystems like NTFS, UFS and even ZFS.
Physical disk can be: /dev/da4 or /dev/label/mycooldisk or /dev/da4p3 (third partition on disk da4)
vdev can be mirror of 2 disks, raid-z of 8 disks or raid-z2 of 4 disks
pool can be "mypool" mounted on /mypool and have one or more vdevs as 'backing' for its storage.
zvol can be "/dev/zvol/MYVOLUME" as created with zfs create -V 5g mypool/MYVOLUME
Nice to know it still works. And yes i might change the "RAID" description. But to make things even more complicated; RAID-Z really is not a RAID spec at all; ZFS does not support "RAID". RAID is an on-disk specification which allows you to use multiple drives to reconstruct a virtual single device. This 'virtual harddisk' is then fed to the (NTFS?) filesystem. But with RAID-Z, no ordinary RAID engine could ever reproduce the way ZFS uses it; it wouldn't be possible to write everything to a larger single disk, such as is possible with any 'real' RAID scheme.
The current RAID scheme is flawed and only lives on due to it being a recognizable term for using multiple disks to store the same data. RAID-Z might only make that more complicated. However, for the user, it closely mimics the characteristics of RAID5 (one disk can completely fail but no more; space = n-1 or n-2 for raidz2). So i will have to think about correct terminology.
About ZVOLs: these are little virtual harddrives themselves. So imagine you have a 4GB ZVOL on your 2000GB ZFS filesystem; it would start to consume 4GB of space right away. Now this ZVOL acts just like a harddrive for most intents and purposes. You could format it with UFS, even create a new ZFS pool on this ZVOL. It's like a harddrive whose actual storage is mapped to a file on ZFS; this special file type is called a ZVOL.
ZVOLs can be useful for many things, but primarily it's iSCSI which uses these. iSCSI is a SAN protocol so the underlying filesystem would be different. Windows booting with iSCSI could store its NTFS filesystem on the ZVOL; which is actually stored on ZFS. Since ZFS is the underlying storage device, things like checksums, de-duplication and compression all work on the ZVOL even though NTFS may not support these features.
NAS protocols like Samba, NFS and FTP, however, use the server-side filesystem to locate and process files. So with these protocols you would not be using ZVOLs but just ordinary files on ZFS filesystem.
Edit: to help understanding the place of ZVOLs, let me list all of them:
disk: physical disk fed to ZFS; can be a partition, a labeled disk, or whole disk
vdev: an array like RAID-Z, mirror or single device, with one or more disks attached to it
pool: a combined volume which has at least one vdev. If it contains multiple vdevs (arrays) then all free space is combined as a whole and available to any location on the pool. Thus a pool is a collection of vdevs.
zvol: an optional 'virtual disk' that behaves just like a block-level device (harddrive) and can be used to store basically anything; including other filesystems like NTFS, UFS and even ZFS.
Physical disk can be: /dev/da4 or /dev/label/mycooldisk or /dev/da4p3 (third partition on disk da4)
vdev can be mirror of 2 disks, raid-z of 8 disks or raid-z2 of 4 disks
pool can be "mypool" mounted on /mypool and have one or more vdevs as 'backing' for its storage.
zvol can be "/dev/zvol/MYVOLUME" as created with zfs create -V 5g mypool/MYVOLUME
Last edited:
wingfat
Weaksauce
- Joined
- May 13, 2010
- Messages
- 115
Sub...
You should seriously write a book.. Your explanations are so easy to understand. Thank You..
I have been using the file browser to look at /etc/rc.conf (for example). When I select the file itself the interface brings me back to the prior directory listing rather then allowing me to open/edit the file. Is this the correct behavior? Thanks..
You should seriously write a book.. Your explanations are so easy to understand. Thank You..
I have been using the file browser to look at /etc/rc.conf (for example). When I select the file itself the interface brings me back to the prior directory listing rather then allowing me to open/edit the file. Is this the correct behavior? Thanks..
Yes it does not list the contents of the file yet; and has some other minor issues. But it's the basis for a much cooler 'norton commander' like file manager where you can copy over stuff, backup stuff, view files/pictures and also download/upload files from your browser.
- Status