You can get something like this with LVM snapshots. I saw someone on the lists that has a snapshot daily, weekly, and monthly. You just need the extra space not allocated to a logical volume to hold the old snapshot COW[1] data.
[1] Copy On Write. LVM slits your volumes into chunks and when you make a snapshot, and attempt to write to it, it copies that chunk to an unallocated chunk and writes the changes there.
After spending enough time in the ext2 and ext3 mailing lists and reading various articles, I can give an answer to you, but don't remember any single source that gives the information by itself. I'm going to concentrate on ext3's journaling since that's the one I'm the most familiar with.
First of all I'm assuming "doubling the data and filesystem" means writing the data to the journal before writing it to the rest of the filesystem.
The simple answer is that most journaling filesystems don't log the data, only the filesystem information about the data (meta-data "data about data"). So unless the filesystem claims "data journaling" it only journals meta-data. Ext3 was the only filesystem that could claim this until recently when Suse added the capability to ReiserFS (aka Reiser3) in the 2.6 kernel. Before that it was only in the Suse 2.4 vendor kernel. Also, Reiser4 is completely data journaling, but they have found a way to optimize the writing operations. I think they have split the journal across the disk and then reasign the journal to new locations so there isn't a need for two writes, but I'm sure I don't understand it completely and I haven't seen it stated very clearly anywhere yet on how it works.
So, if you don't data-journal, then what do you do? The key is ordering. You leave the meta-data and data blocks alone while putting the updates in the journal. So, in the filesystem you have one inode (file) that uses blocks 1, 2 and 3, but your updates go to blocks 4, 5 and 6. And then once that write operation is complete the block list change is written to the inode in the filesytem.
There are drawbacks though. How do you define a "write operation"? The most common way to save a file is to truncate (set it's size to zero), and then write the entire file over. So, it is entirely possible for a truncate call to make it to the journal and when the journal is replayed you get a zero length file instead of your data. And each write() call usually is 4k of data (application dependant). So having a journal doesn't insure you against partial or missing data, only that the latest state of the filesystem written to disk will be the same when you crash or lose power.
The problem is that there is no standard programming interface (API) to define a write transaction. Reiser4 is developing one with a limit of 64 write calls (per user?) (last time I was watching the lists which was about four months ago). The reason there is a limit is because you could exhaust the journal space with reservations from a malicous program very easily if there wasn't a limit. The plan is to let the API be defined within Reiser4 (they have submitted an RFC to LKML a while back IIRC), and then let it be moved up a layer when other filesystems start implementing transaction reservations in their filesystem.
"already quite often had cases where software in 'Debian stable', was either a lot more buggy or even completly unusable[1] compared to 'unstable'. Upstream after all also makes progress and fixes bugs, yet, due to Debians policies, none of these bugfixes ever went into 'stable', since stable basically means "don't touch" and only change something for security reason."
Yes, this is very true. Fortunately, Fedora has the policy to update the base version for bug and security fixes.
I've only used Debian and Fedora Core 2. Does anyone else know if other distributions have the same policy as Fedora?
The driver would be mapped into the X11 server process since that's how the Xfree implementation works with drivers (Xfree is in userspace).
Other posters have made arguments that the binary driver can be in userspace, and I don't need to repeat that.
Nvidia has *not* been very open to the community, as far as specs and source goes. Their Nforce chipset had to be reverse engeniered before things started working properly.
Any vendor that doesn't say "it works with this linux kernel version or later" or provides kernel-mode drivers with source is not "open source friendly".
That's not the point. From what I can tell, Helix isn't meant to add anything you couldn't do before, it's Real's attempt to cash in on the developer base in the OSS community.
Now that Helix is GPL, Real can copy any other GPL code into their client and use GPLed libs, which drastically reduces their maintenance costs.
Now they can put more resources into their codec, and marketing which can't do anything but help everyone, since it's not a MS locked in format.
Can anyone compare Lustre and GFS as far as their archatecture goes?
They're both GPL, but Lustre only releases their previous stable release under the GPL license, so there's not much chance of an OSS community forming around it since the development isn't open, only the old code.
I haven't used it, but from what I understand GFS should be thought of as part of the block layer, like Software Raid, not a filesystem like reiserfs or reiser4.
And you are spouting nonsense about a plugin for reiser4 that doesn't make any sense at that layer, unless they're trying to re-implement what gfs does, or interact with it in some way.
As it is, reiser4 should work with gfs without needing a plugin.
GFS is not a replacement for NFS or any other type of file serving over a network.
GFS allows several systems connected to the same storage device to coordinate write access to the filesystem on that device so that they don't corrupt the changes the other nodes have made the filesystem.
In other words, it makes sure each node knows what the others have done.
That being said, LinuxHA has solved the problem where one NFS server goes down, and another serving the same files to take it's place for several years.
In fact, GFS will allow two NFS servers to serve from the same storage at the same time (active/active using HA lingo).
Keeping to typical non-database driven sites, a hosting company could save costs, maintenance, and provide superb response times if they used this archatecture (please do your best to tear it apart):
I'm starting with the premise that this is one location, but it can work with multiple locations also.
Network: Two or more Ethernet switches each with seperate power supplies, and possibly in different rooms.
File Servers: Each Ethernet switch contains two or more replicated OpenAFS fileservers.
Web servers: Each web server connects to the OpenAFS fileservers as a client.
load balancers: Use whatever load balancer you prefer Nortel, Foundry, or Linux server, it's up to you.
Now, why is this better than using rsync? Because every server is in the pool to serve every web site you're hosting. You only need to spend money on extra storage in the file servers.
The way OpenAFS works, is that each client caches the files it opens on the disk. That means the most recently and often used files stay on the web server's OpenAFS cache, so it dynamically adjusts to usage patterns of the users. And most web sites don't get hits on all of their files, only a few high traffic areas.
So, what happens when slashdot gets ahold of one of these sites? Well, with your average hosting company having hundreds of web servers, I doubt even slashdot could take them down unless they saturated their net connection.
A couple web servers go down? No problem, the load balancer will route around.
A file server goes down? No problem, you have the other fileserver on the same switch to take the extra load, in fact the fileservers on the other switches can take some of the load also.
An ethernet switch goes down? No problem, you have the other switches to take up the load.
Load balancer goes down? No problem, just use one load balancer per ethernet switch server group, or use an upstream load balancer or even dns round-robin.
Now once you get into the database servers, that's a different story where GFS coupled with LinuxHA would be a great match.
Re:Not quite, but OpenAFS would be a good option
on
Red Hat announces GFS
·
· Score: 1
I encourage you to give OpenAFS a shot unless you have any file locking requirements.
As for the non-posix semantics, if you're not using cross-directory hard links, don't require files larger than 2GB (that limit is fixed in the 1.3 development version), then you shouldn't notice anything.
Also, the ACLs have much richer functionality compared to the standard UGO (User, Group, Other) Octal permissions.
I have another post with more details...
Re:Not quite, but OpenAFS would be a good option
on
Red Hat announces GFS
·
· Score: 2, Interesting
I'm also wondering about how GFS compares with OpenAFS. I've looked into OpenAFS, and if you require any type of locking, you shouldn't use OpenAFS (though, I'm not sure about "lock file" semantics with OpenAFS).
o fcntl locks are "always granted" meaning you won't know if anyone else is using any file on AFS.
o It doesn't support hard links between files in different directories because their ACLs are directory based, not volume based.
o Permissions are based on AFS acls, and the standard unix octal permissions will show in file listings, but mean nothing.
o The stable version (v. 1.2) has a 2GB file size (though volume size can be much larger) limit.
o Depending on the length of your file names, you are limited to approx. 64k or fewer files per directory.
o Currently it only supports 2.4 kernels stably, and there is some strife between the OpenAFS and Linux Kernel communities on the implementation. Specifically, they don't like that the syscall table is not exported to modules in Linux 2.6 (they say it is for all other Unix-like OSes...)
o OpenAFS isn't GPLed (it uses an IBM open source license that's GPL incompatible). So, unless there's a rewrite, it won't get into the mainstream kernel. There seems to be some progress made on a GPLed rewrite for the 2.6 kernel, but it is very experemental and only provides some functionality compared to the OpenAFS non-gpl module.
AFS as it is now is best for a distributed file sharing network where locking isn't important. With its one read/write server, and multiple read-only servers per volume it would be a great tool to maintain mirrors (read the OpenAFS docs on what exactly a volume is, and the concepts that suround them). It has great caching concepts, and only sends the parts of the files you request (unlike Coda that must send the entire file before the first byte is available to userspace).
GFS looks like it will be a great tool for the LinuxHA project for active/active pairs of nodes.
Given time, I'm sure GFS will be in all distributions that value cluster admins as users (suse, debian, etc).
Caldera in the printing industry
on
Wired on McBride
·
· Score: 4, Interesting
I work for a company that has Ikon printers. They use Sun Solaris as their print "controllers" that rip the data (postscript, pcl, etc) and send it to the printers.
We almost got a "TCO Box" that connects an OCe printer with native Bus & Tag (old IBM mainframe technology) to a TCP/IP network. It ran Caldera Linux. Which they're in the process of switching to Suse (though, that's not set in stone).
One interesting thing is that in the price breakdown the "Linux operating system" was $700! I asked what type it was, but never got a response. I wouldn't have known it was Caldera unless I was there to see the tech boot it up and configure it.
While I'm happy to see any company see the light of Linux, it's too bad they succumed to the dim light that Caldera turned into.
We don't know how many bugs are left in code. There are only a limited number of patents. The comparison is senseless.
Not really.
Ogg vorbis can not compare their methods with any patents that are in the review process. And once the patent is granted, prior art has to be before the application date! IIRC.
IP/SEC traffic requires certain very specific protocols and ports to be opened which may not normally be open on a standard ISP network.
True
Most legacy hardware, and much current hardware doesn't support IP/SEC, so it cannot work.
Wrong. You do *NOT* need anything more than the ability to forward protocol 50 (like tcp and udp are protocol 6 and 17 respectively) and allow udp port 500 through their network firewalls (if they have them), or routers.
This is *basic* IP functionality needed to forward any type of internet traffic! In fact, if the devices (routers, transparent proxies, etc.) tried to modify the packets, that would disable IP/Sec, not "Support" it.
If you didn't know, now you know. Otherwise, you just look like someone who has half knowledge and is trying to pass off as something you're not.
Slashdot Mirror
You can get something like this with LVM snapshots. I saw someone on the lists that has a snapshot daily, weekly, and monthly. You just need the extra space not allocated to a logical volume to hold the old snapshot COW[1] data.
[1] Copy On Write. LVM slits your volumes into chunks and when you make a snapshot, and attempt to write to it, it copies that chunk to an unallocated chunk and writes the changes there.
After spending enough time in the ext2 and ext3 mailing lists and reading various articles, I can give an answer to you, but don't remember any single source that gives the information by itself. I'm going to concentrate on ext3's journaling since that's the one I'm the most familiar with.
First of all I'm assuming "doubling the data and filesystem" means writing the data to the journal before writing it to the rest of the filesystem.
The simple answer is that most journaling filesystems don't log the data, only the filesystem information about the data (meta-data "data about data"). So unless the filesystem claims "data journaling" it only journals meta-data. Ext3 was the only filesystem that could claim this until recently when Suse added the capability to ReiserFS (aka Reiser3) in the 2.6 kernel. Before that it was only in the Suse 2.4 vendor kernel. Also, Reiser4 is completely data journaling, but they have found a way to optimize the writing operations. I think they have split the journal across the disk and then reasign the journal to new locations so there isn't a need for two writes, but I'm sure I don't understand it completely and I haven't seen it stated very clearly anywhere yet on how it works.
So, if you don't data-journal, then what do you do? The key is ordering. You leave the meta-data and data blocks alone while putting the updates in the journal. So, in the filesystem you have one inode (file) that uses blocks 1, 2 and 3, but your updates go to blocks 4, 5 and 6. And then once that write operation is complete the block list change is written to the inode in the filesytem.
There are drawbacks though. How do you define a "write operation"? The most common way to save a file is to truncate (set it's size to zero), and then write the entire file over. So, it is entirely possible for a truncate call to make it to the journal and when the journal is replayed you get a zero length file instead of your data. And each write() call usually is 4k of data (application dependant). So having a journal doesn't insure you against partial or missing data, only that the latest state of the filesystem written to disk will be the same when you crash or lose power.
The problem is that there is no standard programming interface (API) to define a write transaction. Reiser4 is developing one with a limit of 64 write calls (per user?) (last time I was watching the lists which was about four months ago). The reason there is a limit is because you could exhaust the journal space with reservations from a malicous program very easily if there wasn't a limit. The plan is to let the API be defined within Reiser4 (they have submitted an RFC to LKML a while back IIRC), and then let it be moved up a layer when other filesystems start implementing transaction reservations in their filesystem.
Did that answer your question?
You mean there were alternate source code trees that had patches to do 3D acceleration?
The last I heard, the patches would be submitted, but never acknowledged and integrated.
Too bad a patchset for xfree86 didn't spring up that followed the latest releases.
Oh well, we have XOrg now so it's a moot point.
Sorry, but Debian does patch their kernels.
My god. Have you seen how big it is?
:-D
Yeah, and it's especially painful as it rubs against the zipper when I don't wear my boxers.
Did the gentoo installer run on a 2.6 kernel?
If not, then they avoided the problem that way, not by fixing it.
"already quite often had cases where software in 'Debian stable', was either a lot more buggy or even completly unusable[1] compared to 'unstable'. Upstream after all also makes progress and fixes bugs, yet, due to Debians policies, none of these bugfixes ever went into 'stable', since stable basically means "don't touch" and only change something for security reason."
Yes, this is very true. Fortunately, Fedora has the policy to update the base version for bug and security fixes.
I've only used Debian and Fedora Core 2. Does anyone else know if other distributions have the same policy as Fedora?
Yeah, because it was released back in the last ice age?
Disclaimer: I've use debian since 1999!
> If the driver is mapped into the process
The driver would be mapped into the X11 server process since that's how the Xfree implementation works with drivers (Xfree is in userspace).
Other posters have made arguments that the binary driver can be in userspace, and I don't need to repeat that.
Nvidia has *not* been very open to the community, as far as specs and source goes. Their Nforce chipset had to be reverse engeniered before things started working properly.
Any vendor that doesn't say "it works with this linux kernel version or later" or provides kernel-mode drivers with source is not "open source friendly".
No.
Since SPF checks the envelope, only if you are not in the spf record for your domain and if you have it set to hard fail would your message bounce.
So the answer is "it will work if you don't fsck it up!"
I hope you're joking and know that you're supposed to read that as "LinuxHA has had nfs server hot-failover for several years"...
That's not the point. From what I can tell, Helix isn't meant to add anything you couldn't do before, it's Real's attempt to cash in on the developer base in the OSS community.
Now that Helix is GPL, Real can copy any other GPL code into their client and use GPLed libs, which drastically reduces their maintenance costs.
Now they can put more resources into their codec, and marketing which can't do anything but help everyone, since it's not a MS locked in format.
Can anyone compare Lustre and GFS as far as their archatecture goes?
They're both GPL, but Lustre only releases their previous stable release under the GPL license, so there's not much chance of an OSS community forming around it since the development isn't open, only the old code.
I sincerely doubt there will be anyone in the debian community quibbling with a GPL license.
Once there is a debian developer with interest in maintaining a gfs package, it will be there.
Also, check out apt-get.org. It may package gfs faster.
No, GFS and oMFS are no similar at all.
oMFS doesn't access the remote block device, it is basically what NFS gives you, except with coherency.
With oMFS, different clients reading and writing to the same file will see each other's changes in a reliable way (not counting bugs).
NFS doesn't do that.
I haven't used it, but from what I understand GFS should be thought of as part of the block layer, like Software Raid, not a filesystem like reiserfs or reiser4.
And you are spouting nonsense about a plugin for reiser4 that doesn't make any sense at that layer, unless they're trying to re-implement what gfs does, or interact with it in some way.
As it is, reiser4 should work with gfs without needing a plugin.
GFS is not a replacement for NFS or any other type of file serving over a network.
GFS allows several systems connected to the same storage device to coordinate write access to the filesystem on that device so that they don't corrupt the changes the other nodes have made the filesystem.
In other words, it makes sure each node knows what the others have done.
That being said, LinuxHA has solved the problem where one NFS server goes down, and another serving the same files to take it's place for several years.
In fact, GFS will allow two NFS servers to serve from the same storage at the same time (active/active using HA lingo).
Keeping to typical non-database driven sites, a hosting company could save costs, maintenance, and provide superb response times if they used this archatecture (please do your best to tear it apart):
I'm starting with the premise that this is one location, but it can work with multiple locations also.
Network:
Two or more Ethernet switches each with seperate power supplies, and possibly in different rooms.
File Servers:
Each Ethernet switch contains two or more replicated OpenAFS fileservers.
Web servers:
Each web server connects to the OpenAFS fileservers as a client.
load balancers:
Use whatever load balancer you prefer Nortel, Foundry, or Linux server, it's up to you.
Now, why is this better than using rsync? Because every server is in the pool to serve every web site you're hosting. You only need to spend money on extra storage in the file servers.
The way OpenAFS works, is that each client caches the files it opens on the disk. That means the most recently and often used files stay on the web server's OpenAFS cache, so it dynamically adjusts to usage patterns of the users. And most web sites don't get hits on all of their files, only a few high traffic areas.
So, what happens when slashdot gets ahold of one of these sites? Well, with your average hosting company having hundreds of web servers, I doubt even slashdot could take them down unless they saturated their net connection.
A couple web servers go down? No problem, the load balancer will route around.
A file server goes down? No problem, you have the other fileserver on the same switch to take the extra load, in fact the fileservers on the other switches can take some of the load also.
An ethernet switch goes down? No problem, you have the other switches to take up the load.
Load balancer goes down? No problem, just use one load balancer per ethernet switch server group, or use an upstream load balancer or even dns round-robin.
Now once you get into the database servers, that's a different story where GFS coupled with LinuxHA would be a great match.
I encourage you to give OpenAFS a shot unless you have any file locking requirements.
As for the non-posix semantics, if you're not using cross-directory hard links, don't require files larger than 2GB (that limit is fixed in the 1.3 development version), then you shouldn't notice anything.
Also, the ACLs have much richer functionality compared to the standard UGO (User, Group, Other) Octal permissions.
I have another post with more details...
I'm also wondering about how GFS compares with OpenAFS. I've looked into OpenAFS, and if you require any type of locking, you shouldn't use OpenAFS (though, I'm not sure about "lock file" semantics with OpenAFS).
o fcntl locks are "always granted" meaning you won't know if anyone else is using any file on AFS.
o It doesn't support hard links between files in different directories because their ACLs are directory based, not volume based.
o Permissions are based on AFS acls, and the standard unix octal permissions will show in file listings, but mean nothing.
o The stable version (v. 1.2) has a 2GB file size (though volume size can be much larger) limit.
o Depending on the length of your file names, you are limited to approx. 64k or fewer files per directory.
o Currently it only supports 2.4 kernels stably, and there is some strife between the OpenAFS and Linux Kernel communities on the implementation. Specifically, they don't like that the syscall table is not exported to modules in Linux 2.6 (they say it is for all other Unix-like OSes...)
o OpenAFS isn't GPLed (it uses an IBM open source license that's GPL incompatible). So, unless there's a rewrite, it won't get into the mainstream kernel. There seems to be some progress made on a GPLed rewrite for the 2.6 kernel, but it is very experemental and only provides some functionality compared to the OpenAFS non-gpl module.
AFS as it is now is best for a distributed file sharing network where locking isn't important. With its one read/write server, and multiple read-only servers per volume it would be a great tool to maintain mirrors (read the OpenAFS docs on what exactly a volume is, and the concepts that suround them). It has great caching concepts, and only sends the parts of the files you request (unlike Coda that must send the entire file before the first byte is available to userspace).
GFS looks like it will be a great tool for the LinuxHA project for active/active pairs of nodes.
Given time, I'm sure GFS will be in all distributions that value cluster admins as users (suse, debian, etc).
I work for a company that has Ikon printers. They use Sun Solaris as their print "controllers" that rip the data (postscript, pcl, etc) and send it to the printers.
We almost got a "TCO Box" that connects an OCe printer with native Bus & Tag (old IBM mainframe technology) to a TCP/IP network. It ran Caldera Linux. Which they're in the process of switching to Suse (though, that's not set in stone).
One interesting thing is that in the price breakdown the "Linux operating system" was $700! I asked what type it was, but never got a response. I wouldn't have known it was Caldera unless I was there to see the tech boot it up and configure it.
While I'm happy to see any company see the light of Linux, it's too bad they succumed to the dim light that Caldera turned into.
Does anyone have any articles for this?
Not really.
Ogg vorbis can not compare their methods with any patents that are in the review process. And once the patent is granted, prior art has to be before the application date! IIRC.
Someone, please mod the parrent post up as funny!
True
Most legacy hardware, and much current hardware doesn't support IP/SEC, so it cannot work.
Wrong. You do *NOT* need anything more than the ability to forward protocol 50 (like tcp and udp are protocol 6 and 17 respectively) and allow udp port 500 through their network firewalls (if they have them), or routers.
This is *basic* IP functionality needed to forward any type of internet traffic! In fact, if the devices (routers, transparent proxies, etc.) tried to modify the packets, that would disable IP/Sec, not "Support" it.
If you didn't know, now you know. Otherwise, you just look like someone who has half knowledge and is trying to pass off as something you're not.
Mike