Re: File Server with OpenBSD?
>> mtree(8) with -K sha1digest might be enough, and is in the base >> system. >It's a bit more complicated. You have a bitrot if the file checksum >changed >AND the modification time hasn't changed. Files that are updated will be >reported as corrupted, which may be boring. >If you have archiving static data, the mtree method works though. There is also ./archivers/par2cmdline which lets you create redundancy for files. It is a lot higher in system (above file system), so you would need to make scripts to use frequently. It also doesn't create redundancy for filesystem's metadata. It would not harden your file system.
Re: File Server with OpenBSD?
Tue, 7 Mar 2017 16:29:12 + (GMT) Roderick > Before I make a decision, I want to ask you for suggestions. Hi Roderick, As you probably know well already, read _carefully_ Nick Holland's advice to this (and previous) threads in the OpenBSD mailing lists. These will, most definitely, present you important pointers to evade common pitfalls. > I want to make a small file server, just to separate important > files from my working system. This simplified definition makes your solution quite obvious: a networked computer exposing your data to the other systems. This also defines your all other important aspects towards the sub-defined requirements and also is the basis for providing the solutions to all of these sub-definitions. > Two disks as Raid 1. Files are to > be read with NFS. Emphasis: OpenBSD provides these easily, you will have no problem implementing your solution, just use the minimum required hardware and configuration setup. > (1) Data Integrity (not security :). > > (2) some degree of indepencence from hardware and operating system. > Disk are to be readable for many decades. Standard File System > readable after moving the Disks to another computer, different > hardware, perhaps with different OS. The pointers in the thread are quite well suited with one minor omission. The independence of hardware and operating system to ensure your data and not only disks but the actual stored information is readable for the long periods you design is given by: the standards, and by the protocols used. The longest available and stable is, the Ethernet network periphery port. Just make sure you expose your data over multiple protocols, and not only the one you use to access it in production, e.g. add file synchronisation and more than one data carrier protocol for archival and you're all done. Kind regards, Anton > I was thinking on doing it with FreeBSD and ZFS. I find the last > interesting because: (a) it make checksums and corrections if > a checksum in a disk is wrong (using the other disk in the array), > (b) many OS are implementing it. But I find horrible how > resource hungry it is. > > Do you have an idea? > > I do preffer OpenBSD, but is there an appropriate file system > for archiving? > > I thank for any suggestion > Rodrigo.
Re: File Server with OpenBSD?
On Thu, 9 Mar 2017, Karel Gardas wrote: I ask this because I want to know if I will make me dependent of todays stand of OpenBSD. Mounting ffs partitions of OpenBSD in FreeBSD and the opposite is possible without big problems. Will this change with Raid? Yes, as FreeBSD does not know anything about OpenBSD's software raid. And even "ccd" seems not to be a solution. We read in the man page of FreeBSD: Note that a one-disk ccd is not the same as the original partition. In particular, this means if you have a file system on a two-disk mirrored ccd and one of the disks fail, you cannot mount and use the remaining partition as itself; you have to configure it as a one-disk ccd. << Perhaps is too naive to think it would be enough to edit the label, RAID seems to be a complicated issue. ccd lived long (not anymore in OpenBSD), but I do not know if the versions in the many BSDs are compatible. And if ZFS will live longer than the hype is also a big question. No way to avoid frequent backup, migration and system mutation for the simplest use. Rodrigo.
Re: File Server with OpenBSD?
On Thu, Mar 9, 2017 at 12:13 PM, Roderick wrote: > And where are the planned checksums written? First version divided partition to data and checksum areas which means RAID1 with checksums and RAID1 were compatible in a sense that if something terribly happen in checksumming code, then you still may get data while attaching as RAID1. Current version is using 512k data + 4k checkksum scheme which makes it incompatible with plain RAID1. > I ask this because I want to know if I will make me dependent of > todays stand of OpenBSD. > > Mounting ffs partitions of OpenBSD in FreeBSD and the opposite > is possible without big problems. Will this change with Raid? Yes, as FreeBSD does not know anything about OpenBSD's software raid. Karel
Re: File Server with OpenBSD?
I want to make my questions below more concrete. Let us suppose, I boot from wd0 and want to make a Raid 1 with wd1 and wd2, and that I follow the instructions in "man softraid": # printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd1 # printf "a\n\n\n\nRAID\nw\nq\n\n" | disklabel -E wd2 # bioctl -c 1 -l /dev/wd1a,/dev/wd2a softraid0 # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1 # ... disklabel in sd0 , new ffs there, ... What did happen? Where did bioctl wrote data? Where is written the new label in sd0? I will not be able to mount wd1 or wd2 as a single disc with ffs, but perhaps modifying the label? And where are the planned checksums written? I ask this because I want to know if I will make me dependent of todays stand of OpenBSD. Mounting ffs partitions of OpenBSD in FreeBSD and the opposite is possible without big problems. Will this change with Raid? Thanks Rodrigo. On Wed, 8 Mar 2017, Roderick wrote: Few questions: (1) Where are the checksums written? (2) Where are the metadata of Raid 1 / Raid 1 with Checksum written? (3) Can I take a disc from the Raid array and mount it somewhere else as a normal ufs single disk? (4) Well, sooner than Hammer2, but when? :)
Re: File Server with OpenBSD?
Le 2017-03-08 16:25, Raimo Niskanen a écrit : On Tue, Mar 07, 2017 at 05:55:08PM +0100, Solène Rapenne wrote: Le 2017-03-07 17:29, Roderick a écrit : For data integrity, you may use sysutils/bitrot to check for data integrity (bit rot). mtree(8) with -K sha1digest might be enough, and is in the base system. It's a bit more complicated. You have a bitrot if the file checksum changed AND the modification time hasn't changed. Files that are updated will be reported as corrupted, which may be boring. If you have archiving static data, the mtree method works though.
Re: File Server with OpenBSD?
On Tue, Mar 07, 2017 at 05:55:08PM +0100, Solène Rapenne wrote: > Le 2017-03-07 17:29, Roderick a écrit : > For data integrity, you may use sysutils/bitrot to check for data > integrity (bit rot). mtree(8) with -K sha1digest might be enough, and is in the base system. > With OpenBSD, you won't get snapshots, on-the-fly compression etc... > > Don't forget backups, that the most important thing for your file server > :-) Oh yes! -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: File Server with OpenBSD?
2017-03-08 13:52 GMT+01:00 Roderick : > > On Tue, 7 Mar 2017, Nick Holland wrote: > > The point is, you can't design ONE box for ten years of life. With >> modern SSD tech, I suspect you won't see a SATA port on a computer in >> ten years. >> > > But we can try to speculate. I guess, we will have USB Ports for long > time. You see that the old RS232 is still alive. And we will have adapters > to read old discs. > Hard to buy computers with serial ports these days, also I have several USB devices that will not work in a USB3 port, but need that I have a usb port in between to get the bus down to USB2 (or 1.1 or 1) speeds before being visible. Not even USB handles obsoletion(sp?) very well, even if adapters exist, but that is just confirming Nicks story to be valid. What if usb4 shows the same issues, then a usb4->3 usb with a 3->2 hub after? All so that I don't have to move the data every X years... -- May the most significant bit of your life be positive.
Re: File Server with OpenBSD?
On Tue, 7 Mar 2017, Karel Gardas wrote: Well, as a ZFS replacement I've added checksumming support into SR-RAID1. It was really basic and as simple as possible design and even compatible with plain SR-RAID1, but still was able to detect and self-heal corrupted block too. So if data correctness is your mantra, you don't need whole ZFS for it. Well, I've not submitted my code yet for the second attempt (first you can find in the archive) since I got kind of stuck in rewrite for family/life reasons but I still keep my hope on it and also hope it'll be delivered sooner than HAMMER2... This sounds very good! For my purpose I need less than a Raid continously checking integrity. It would be enough if it is possible to check integrity and correct data from time to time by issuing a command. Few questions: (1) Where are the checksums written? (2) Where are the metadata of Raid 1 / Raid 1 with Checksum written? (3) Can I take a disc from the Raid array and mount it somewhere else as a normal ufs single disk? (4) Well, sooner than Hammer2, but when? :) -- On Tue, 7 Mar 2017, Nick Holland wrote: The point is, you can't design ONE box for ten years of life. With modern SSD tech, I suspect you won't see a SATA port on a computer in ten years. But we can try to speculate. I guess, we will have USB Ports for long time. You see that the old RS232 is still alive. And we will have adapters to read old discs. I fear, the problem will be the firmware of modern discs written on Eprom. We cannot compare old discs with modern ones also due to the density of the data. The same could be said about the tapes. We do not have the experience. Yes, raid does not substitute backup, and one must keep the system alive and mutate it when necesary. There is in my opinion till now no solution for archiving electronic data. Continous migrating is too expensive. Rodrigo.
Re: File Server with OpenBSD?
On 03/07/17 13:21, Roderick wrote: > On Tue, 7 Mar 2017, Christian Weisgerber wrote: > >> On 2017-03-07, Roderick wrote: >> >>> Disk are to be readable for many decades. Standard File System >>> readable after moving the Disks to another computer, different >>> hardware, perhaps with different OS. >> >> *uncontrollable laughter* > > Then you got, what is the problem. But it is not for laughing, it was > the escense of my question. > > I can read till now very old SCSI disks, also 3 1/2'' floppies, but > not always 5 1/4'' (because of the low level formatting). Of course, > depending on the file system. I would not use FAT, ufs would be a > good choice. actually, I've had far better luck reading 5.25" floppies than old 3.5". Last time I checked my 8" floppies, they were doing better than the 5.25". In fact, I've got the gear to calibrate a 5.25" and 8" floppy drive -- you "repair" a 3.5" floppy drive with the trashcan. Which is great..assuming you can get a new one. Very old SCSI and IDE disks that made it five years usually made it a lot longer (and some never seem to die). However, I'm seeing a continued decline in long term product reliability as prices continue to plummet in the IT world. I really don't think you will be seeing ten year old 2TB SATA (or SAS) disks very often. (please don't quote MTBFs to me, it makes me laugh for a moment, and then I get sad when I realize people believe that shit) Technology changes. Hard to tell when. A number of years ago, I had an opportunity to buy a bunch of IDE to SCSI enclosures for really cheap. I ... uh ... loaded up. These things were great -- 16 IDE disks, attached to one SCSI port -- you could carve up the array into multiple virtual drives, and I was thinking, "wow...16 500G disks...that's a lot of storage! 1TB disks are coming soon, too!" Well, very shortly after I acquired the last of these things, the market turned, and SATA killed IDE. Only a few token IDE disks remained being produced, and they were EXPENSIVE compared to the SATAs. I found a cute little IDE to SATA adapter that actually fit in the array's trays, but then I quickly discovered that 1T was the limit of the array's disk handling abilities. Meanwhile, the rest of the world said, "What's SCSI?" -- finding something to plug the array into was becoming a trick. I.e., I loaded up on a lot of junk. And someone was freaking brilliant to know when to get OUT of that technology. The point is, you can't design ONE box for ten years of life. With modern SSD tech, I suspect you won't see a SATA port on a computer in ten years. What you need to do is have simple, reliable, and movable solutions, where the REPLACEMENT of the solution is part of it. Your desire to be able to move the disks from one computer to another is good -- when your base hw dies, you need to be able to transport your disks to something else. I can't think of another OS that does that better than OpenBSD. But you take that opportunity as a clue that maybe you need to update your tech, too. Build a simple solution with simple hw of today. When that hw starts getting old and looking rather "different" than newer hw, migrate. Your data is just data, that's what's important. The hw, the platform, the OS, can all be swapped out...AND SHOULD BE swapped out when appropriate. You ain't marrying your solution, quit trying to make it last longer than modern marriages last. A word on ZFS: I've used it. I've used a few features many people probably haven't. It's got a lot of features. It has a huge number of knobs. It's about as anti-OpenBSD as I can imagine, and I'm not talking about the license. It is about as far from "Just Works" as you can get a file system to be anymore. I had a friend tell me once how he'd never want to run a database on anything OTHER than ZFS because of all the file system integrity features. Then he admitted how many times the system crashed on him... Um. crashes for databases are bad, file system magic doesn't change that. My experience with ZFS was that it had the stability of a pig on stilts, and not much more grace. In many ways, ZFS seems to me to be a throwback to the 1980s when file systems needed to be "tuned" and maintained. Your opinion may vary. I know some people who's opinion I respect a lot that think ZFS is the greatest thing ever. I just disagree on that point. Note: OpenBSD's softraid supports three disk RAID1. A lot of people don't understand that -- it's THREE copies of your data. Lose a disk, you still got TWO copies to rebuild from. So my recommendation would be a simple solution that will fit you for maybe two or three years, maybe three disk RAID1, and every two or three years look at your system and the alternatives out there and ask if it makes sense to upgrade now or wait a year or two. Move your data to a new system when appropriate, asking yourself each time, "what's a good solution NOW?". And have an off-site rotated
Re: File Server with OpenBSD?
On Tue, Mar 07, 2017 at 04:39:50PM -0500, alexmcwhir...@triadic.us wrote: > On 2017-03-07 15:57, Karel Gardas wrote: > > RAID10 should be simple. RAID6 is in tree in some form. W.r.t. > > HAMMER2/ZFS as a ZFS user using ZFS solely for more than 10 years > > already, I'm not so keen anymore about COW due to fragmentation. > > Otherwise snapshots are nice, but I'd rather snapshots to be added to > > ffs in not-so-optimal form and whole fs behaving nicely than having > > nice snapshots in ZFS and whole fs killed perf-wise by fragmentation. > > I'll be interested to see how HAMMER2 handles free space fragmentation. A > while back someone on the ZFS team was looking at a way to clean this > fragmentation and rewrite the block pointers. The problem ended up being > that ZFS has so many features that redoing all of the block pointers would > take forever and be very hard to do. Not to mention it also makes adding new > features much more difficult. > > Something like ZFS with a much more limited feature set would be ideal for > this kind of project. But adding FFS snapshots and using softraid would > probably be easier and accomplish the same goal. Or even better, add support for something like lvm snapshots to softraid and don't touch FFS. We could change the default FS in the future without to lose that features. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: File Server with OpenBSD?
What about the some day upcoming RAID1C (RAID1-checksummed)?
Re: File Server with OpenBSD?
On 2017-03-07 15:57, Karel Gardas wrote: RAID10 should be simple. RAID6 is in tree in some form. W.r.t. HAMMER2/ZFS as a ZFS user using ZFS solely for more than 10 years already, I'm not so keen anymore about COW due to fragmentation. Otherwise snapshots are nice, but I'd rather snapshots to be added to ffs in not-so-optimal form and whole fs behaving nicely than having nice snapshots in ZFS and whole fs killed perf-wise by fragmentation. I'll be interested to see how HAMMER2 handles free space fragmentation. A while back someone on the ZFS team was looking at a way to clean this fragmentation and rewrite the block pointers. The problem ended up being that ZFS has so many features that redoing all of the block pointers would take forever and be very hard to do. Not to mention it also makes adding new features much more difficult. Something like ZFS with a much more limited feature set would be ideal for this kind of project. But adding FFS snapshots and using softraid would probably be easier and accomplish the same goal.
Re: File Server with OpenBSD?
On Tue, Mar 7, 2017 at 9:22 PM, wrote: > On 2017-03-07 15:34, Karel Gardas wrote: >> >> So if data correctness is your mantra, you don't need whole ZFS for it. > > > ZFS appeals to me for the snapshots / compression type stuff. Oh, I've mistaken you for OP. >> Well, I've not submitted my code yet >> for the second attempt (first you can find in the archive) since I got >> kind of stuck in rewrite for family/life reasons but I still keep my >> hope on it and also hope it'll be delivered sooner than HAMMER2... > > > HAMMER2 looks good on paper for many reasons, especially the clusters > support. But considering "on paper" is really all we have at the moment, it > will likely be a long time. Either way, it's nice to see soft softraid > development. One of these days i will get around to writing RAID10 and / or > trying to finish up RAID6 if that isn't done by then. RAID10 should be simple. RAID6 is in tree in some form. W.r.t. HAMMER2/ZFS as a ZFS user using ZFS solely for more than 10 years already, I'm not so keen anymore about COW due to fragmentation. Otherwise snapshots are nice, but I'd rather snapshots to be added to ffs in not-so-optimal form and whole fs behaving nicely than having nice snapshots in ZFS and whole fs killed perf-wise by fragmentation.
Re: File Server with OpenBSD?
On 2017-03-07 15:34, Karel Gardas wrote: So if data correctness is your mantra, you don't need whole ZFS for it. ZFS appeals to me for the snapshots / compression type stuff. Well, I've not submitted my code yet for the second attempt (first you can find in the archive) since I got kind of stuck in rewrite for family/life reasons but I still keep my hope on it and also hope it'll be delivered sooner than HAMMER2... HAMMER2 looks good on paper for many reasons, especially the clusters support. But considering "on paper" is really all we have at the moment, it will likely be a long time. Either way, it's nice to see soft softraid development. One of these days i will get around to writing RAID10 and / or trying to finish up RAID6 if that isn't done by then.
Re: File Server with OpenBSD?
On Tue, Mar 7, 2017 at 8:26 PM, wrote: > On 2017-03-07 14:16, Stuart Henderson wrote: >> >> - ZFS *does* checksum, even on mirrors, and can pick which of a pair of >> mirrored drives is good and use it to correct the other one. > > > That i was not aware of, i only thought ZFS did that on RAIDZ pools. No, ZFS does it everywhere on everything. If you do have redundancy on drives, then it may self-heal the corrupted block. > Regardless of whether it will happen or not, I would welcome ZFS into > OpenBSD with arms wide open. Me too, well, or better not. OpenBSD does have completely different philosophy and ZFS is not compatible with it. > In reality though, the only hope for something > like ZFS here is probably HAMMER2, if it's ever finished. Well, as a ZFS replacement I've added checksumming support into SR-RAID1. It was really basic and as simple as possible design and even compatible with plain SR-RAID1, but still was able to detect and self-heal corrupted block too. So if data correctness is your mantra, you don't need whole ZFS for it. Well, I've not submitted my code yet for the second attempt (first you can find in the archive) since I got kind of stuck in rewrite for family/life reasons but I still keep my hope on it and also hope it'll be delivered sooner than HAMMER2...
Re: File Server with OpenBSD?
On 2017-03-07 14:16, Stuart Henderson wrote: - ZFS *does* checksum, even on mirrors, and can pick which of a pair of mirrored drives is good and use it to correct the other one. That i was not aware of, i only thought ZFS did that on RAIDZ pools. Regardless of whether it will happen or not, I would welcome ZFS into OpenBSD with arms wide open. In reality though, the only hope for something like ZFS here is probably HAMMER2, if it's ever finished.
Re: File Server with OpenBSD?
On 2017-03-07, alexmcwhir...@triadic.us wrote: > softraid / regular hardware raid does the same checksumming, ZFS just > implements a ton of extra nice features such as snapshots, compression, > cow, etc... at the cost of a large amount of RAM. It's probably safe to > say we will never see it in OpenBSD with it's current license unless > someone can make it work in ports which is unlikely as it needs a ton of > kernel support. A couple of comments on this: - RAID1 doesn't do checksumming. You don't know which of the copies is correct. - Hardware RAID doesn't give you any protection against bad controllers. - ZFS *does* checksum, even on mirrors, and can pick which of a pair of mirrored drives is good and use it to correct the other one.
Re: File Server with OpenBSD?
I can read till now very old SCSI disks, also 3 1/2'' floppies, but not always 5 1/4'' (because of the low level formatting). Of course, And even much older magnetic tapes are easier to read than floppies.
Re: File Server with OpenBSD?
On Mar 07 16:29:12, hru...@gmail.com wrote: > (2) some degree of indepencence from hardware and operating system. > Disk are to be readable for many decades. Standard File System > readable after moving the Disks to another computer, different > hardware, perhaps with different OS. Just carve the bytes into stone.
Re: File Server with OpenBSD?
On Tue, 7 Mar 2017, Christian Weisgerber wrote: On 2017-03-07, Roderick wrote: Disk are to be readable for many decades. Standard File System readable after moving the Disks to another computer, different hardware, perhaps with different OS. *uncontrollable laughter* Then you got, what is the problem. But it is not for laughing, it was the escense of my question. I can read till now very old SCSI disks, also 3 1/2'' floppies, but not always 5 1/4'' (because of the low level formatting). Of course, depending on the file system. I would not use FAT, ufs would be a good choice. Thanks for the suggestions till now. More suggestions? Rodrigo.
Re: File Server with OpenBSD?
On 2017-03-07, Roderick wrote: > Disk are to be readable for many decades. Standard File System > readable after moving the Disks to another computer, different > hardware, perhaps with different OS. *uncontrollable laughter* -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: File Server with OpenBSD?
On 2017-03-07 11:29, Roderick wrote: Before I make a decision, I want to ask you for suggestions. I want to make a small file server, just to separate important files from my working system. Two disks as Raid 1. Files are to be read with NFS. Emphasis: (1) Data Integrity (not security :). FFS has been around forever, i use it for mission critical data and have never had an issue. No issues with softraid and data integrity either. (2) some degree of indepencence from hardware and operating system. Disk are to be readable for many decades. Standard File System readable after moving the Disks to another computer, different hardware, perhaps with different OS. You can move the disks between any hardware running OpenBSD without issue, as long as the both hardware archs are the same endianess. For example if you take a disk out of an AMD64 box and put it in a SPARC64 box you wont be able to read it because AMD64 is little endian and SPARC64 is big endian. As long as you stay in the same endianess you should be fine as far as i know. As far as other OS's, im not sure. I would think at least NetBSD could read our disk label and maybe FreeBSD, but i have never tested it. I was thinking on doing it with FreeBSD and ZFS. I find the last interesting because: (a) it make checksums and corrections if a checksum in a disk is wrong (using the other disk in the array), (b) many OS are implementing it. But I find horrible how resource hungry it is. Do you have an idea? softraid / regular hardware raid does the same checksumming, ZFS just implements a ton of extra nice features such as snapshots, compression, cow, etc... at the cost of a large amount of RAM. It's probably safe to say we will never see it in OpenBSD with it's current license unless someone can make it work in ports which is unlikely as it needs a ton of kernel support. I do preffer OpenBSD, but is there an appropriate file system for archiving? if you can live without snapshots, compression, cow, etc... FFS will work just fine. I thank for any suggestion Rodrigo.
Re: File Server with OpenBSD?
On Tue, Mar 7, 2017 at 11:55 AM, Solène Rapenne wrote: > Le 2017-03-07 17:29, Roderick a écrit : > >> Before I make a decision, I want to ask you for suggestions. >> >> I want to make a small file server, just to separate important >> files from my working system. Two disks as Raid 1. Files are to >> be read with NFS. Emphasis: >> >> (1) Data Integrity (not security :). >> >> (2) some degree of indepencence from hardware and operating system. >> Disk are to be readable for many decades. Standard File System >> readable after moving the Disks to another computer, different >> hardware, perhaps with different OS. >> >> I was thinking on doing it with FreeBSD and ZFS. I find the last >> interesting because: (a) it make checksums and corrections if >> a checksum in a disk is wrong (using the other disk in the array), >> (b) many OS are implementing it. But I find horrible how >> resource hungry it is. >> >> Do you have an idea? >> >> I do preffer OpenBSD, but is there an appropriate file system >> for archiving? >> >> I thank for any suggestion >> Rodrigo. >> > > > Hello, > > I have my private file server using OpenBSD. That's not the best system > for that but it works. > If you are comfortable with and you don't need extra speed, that will be > ok. > > For data integrity, you may use sysutils/bitrot to check for data > integrity (bit rot). > With OpenBSD, you won't get snapshots, on-the-fly compression etc... > 2 cents: vnconfig /bioctl for RAID1 + CRYPTO for the partition ? CRYPTO will indirectly check for error and RAID1 create redondancy and a way to snaphots all of that. Maybe CRYPTO compress data , or was it a removed option ? > Don't forget backups, that the most important thing for your file server > :-) > > Regards > > -- -- Knowing is not enough; we must apply. Willing is not enough; we must do
Re: File Server with OpenBSD?
Le 2017-03-07 17:29, Roderick a écrit : Before I make a decision, I want to ask you for suggestions. I want to make a small file server, just to separate important files from my working system. Two disks as Raid 1. Files are to be read with NFS. Emphasis: (1) Data Integrity (not security :). (2) some degree of indepencence from hardware and operating system. Disk are to be readable for many decades. Standard File System readable after moving the Disks to another computer, different hardware, perhaps with different OS. I was thinking on doing it with FreeBSD and ZFS. I find the last interesting because: (a) it make checksums and corrections if a checksum in a disk is wrong (using the other disk in the array), (b) many OS are implementing it. But I find horrible how resource hungry it is. Do you have an idea? I do preffer OpenBSD, but is there an appropriate file system for archiving? I thank for any suggestion Rodrigo. Hello, I have my private file server using OpenBSD. That's not the best system for that but it works. If you are comfortable with and you don't need extra speed, that will be ok. For data integrity, you may use sysutils/bitrot to check for data integrity (bit rot). With OpenBSD, you won't get snapshots, on-the-fly compression etc... Don't forget backups, that the most important thing for your file server :-) Regards
File Server with OpenBSD?
Before I make a decision, I want to ask you for suggestions. I want to make a small file server, just to separate important files from my working system. Two disks as Raid 1. Files are to be read with NFS. Emphasis: (1) Data Integrity (not security :). (2) some degree of indepencence from hardware and operating system. Disk are to be readable for many decades. Standard File System readable after moving the Disks to another computer, different hardware, perhaps with different OS. I was thinking on doing it with FreeBSD and ZFS. I find the last interesting because: (a) it make checksums and corrections if a checksum in a disk is wrong (using the other disk in the array), (b) many OS are implementing it. But I find horrible how resource hungry it is. Do you have an idea? I do preffer OpenBSD, but is there an appropriate file system for archiving? I thank for any suggestion Rodrigo.
