Request for Comments: Keeping the OS and Data on phsyically seperated drives
This is a request for comment on a basic hardware and software assignment method. The simplest minimal applied version would be master drive OS and slave drive bearing data. The next higher levels would include replicated data drives. Not needfully in the same machine or even at the same site. So how would you set up an install so the "OS" is on say-HDA and the "Data" on HDB" ? With an implied or even explicit addition of HDC thru HDX as either permanent mirrors or detachable external storage backup. Imaging a data drive is less of a challenge than a live OS. Where this differs from past similar schemes or applications is in the division of OS from Data. The most immediate impact could be for users of multiple OS varieties. The result is a "one user data library - OS Agnostic to the computer accessing it model.The OS needs updating or the drive it is on crashes- your data is safely NOT on the same drive. There are uses for the now open space on the OS drive too. Like process journal buffers as Reiser speculated on. Or pointers to replicant drives holding spatially dispersed copies. EX: /user on a box off site.\ "The Zen of Everything being a file" so far has not covered the WHERE we put the files! Do note that while Linux has had the "ability" to make all this seem trivial- for whatever reasons we seem to not do so. Comments of a value adding nature are welcomed. Open comment form me to the list: Some projects seem to never get past a " "we could- but why?" stage. I'd like to think KCLUG could do better.. " If your OS drive dies- you might be rather glad your data is on at least two other drives" -- Oren Beck 816.729.3645
On Thursday 03 April 2008, Oren Beck wrote:
"The Zen of Everything being a file" so far has not covered the WHERE we put the files! Sure it has.
Anyhow, you should define what you mean by "data". /usr should always be read-only OS files-- it's generally considered safe to mount it read-only in everyday use. /usr/local is another matter, if you use it, and not as well defined. More read-only OS directories: /bin /boot /lib /sbin Configuration should all be in /etc, /usr/local/etc (on some OS), and /home/*/.* User data will always be in /home/* (or /root for root of course). Daemon data is kept in /var
On Thu, Apr 3, 2008 at 2:44 PM, Luke -Jr <luke@dashjr.org> wrote:
On Thursday 03 April 2008, Oren Beck wrote:
"The Zen of Everything being a file" so far has not covered the WHERE we put the files! Sure it has.
Anyhow, you should define what you mean by "data".
/usr should always be read-only OS files-- it's generally considered safe to mount it read-only in everyday use. /usr/local is another matter, if you use it, and not as well defined.
More read-only OS directories: /bin /boot /lib /sbin
Configuration should all be in /etc, /usr/local/etc (on some OS), and /home/*/.*
User data will always be in /home/* (or /root for root of course).
Daemon data is kept in /var
_______________________________________________ Good catch on my potential misstatement of the file description. /usr is indeed what you reminded me. I used the term /user to denote a "named_user" data file.
Yet the core concept is not the merit lacking proposal that it seems to be, IF the "user data" and the operating System" are detached devices- live can get easier for us. Details later. -- Oren Beck 816.729.3645
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely. But you can install to HDA only, then mount HDB as /data and configure/store all your important data there. Thanks, Ron Geoffrion
On Thu, Apr 3, 2008 at 2:52 PM, Geoffrion, Ron P [IT] <Ron.Geoffrion@sprint.com> wrote:
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely.
done every day, for decades. Client/server, tiered architectures do exactly this. As the original, small-disk best practices of keeping data on /var or /var/spool or wherever. With the newer vast hard drives, we've gotten sloppy to the point of forgetting that it was not ever thus. Distributed file systems -- andrew file system, etc -- designed to keep your valuable data in the secure and robust organizational central store so you don't have to worry about which machine you use in the lab or if your laptop gets stolen -- it's all been done. -- bringing useful insights from Computer Science to the larger world
On Thursday 03 April 2008, David Nicol wrote:
On Thu, Apr 3, 2008 at 2:52 PM, Geoffrion, Ron P [IT]
<Ron.Geoffrion@sprint.com> wrote:
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely.
done every day, for decades. Client/server, tiered architectures do exactly this.
I think he meant in regard to OS-independant, which *can be* a problem. KDE configs won't work with GNOME or Windows, and if you load KDE 3.5, you might have problems using your configs in KDE 3.3. Obviously, there would need to be a lot of effort (probably more than it's worth) put into solving this.
On Thu, Apr 3, 2008 at 2:52 PM, Geoffrion, Ron P [IT] <Ron.Geoffrion@sprint.com> wrote:
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely.
done every day, for decades. Client/server, tiered architectures do exactly this.
Well, yes, if you separate the client data from the OS using a network, thumbdrive, or other device that the/many operating system(s) can interface to, sure. I was probably mislead by the question - I thought he wanted to do it on one machine, with the OS on on drive, data on another. We set servers up like that all the time for exactly that reason - OS on the root volume, data on a physically separate volume. 'ot likely' refers to the fact that you have to choose a 'universal' filesystem to swap between OS's on the same machine and access the /data partitions. There are some candidates for that - I'm just not familiar with a really good one when WinDoze it thrown in the OS swap mix. You'd probably end up buy Veritos to mitigate that issue between OSs' Thanks, Ron Geoffrion 913.488.7664
'ot likely' refers to the fact that you have to choose a 'universal' filesystem
anyone using the ext3 drivers for windows? I installed them in January but didn't actually have an ext3 partition on the device (half of a raid set) to mount without additional scaffolding -- bringing useful insights from Computer Science to the larger world
A little late reply, but I'm trying to catch up on email. I have and do use the ext3 drivers for windows. They work well. My Winders XP that I use for DVD copying needed some extra space and it is set up to be dual boot so I grabbed some of the extra space that I had for Linux and used it for temp files for the DVD backup process which can require several GB of space. On Thu, Apr 3, 2008 at 5:05 PM, David Nicol <> wrote:
'ot likely' refers to the fact that you have to choose a 'universal' filesystem
anyone using the ext3 drivers for windows? I installed them in January but didn't actually have an ext3 partition on the device (half of a raid set) to mount without additional scaffolding
-- bringing useful insights from Computer Science to the larger world
On Thu, Apr 3, 2008 at 4:24 PM, Geoffrion, Ron P [IT] <Ron.Geoffrion@sprint.com> wrote:
On Thu, Apr 3, 2008 at 2:52 PM, Geoffrion, Ron P [IT] <Ron.Geoffrion@sprint.com> wrote:
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely.
done every day, for decades. Client/server, tiered architectures do exactly this.
Well, yes, if you separate the client data from the OS using a network, thumbdrive, or other device that the/many operating system(s) can interface to, sure.
I was probably mislead by the question - I thought he wanted to do it on one machine, with the OS on on drive, data on another. We set servers up like that all the time for exactly that reason - OS on the root volume, data on a physically separate volume.
'ot likely' refers to the fact that you have to choose a 'universal' filesystem to swap between OS's on the same machine and access the /data partitions. There are some candidates for that - I'm just not familiar with a really good one when WinDoze it thrown in the OS swap mix. You'd probably end up buy Veritos to mitigate that issue between OSs'
Thanks,
Ron Geoffrion 913.488.7664
Ron, THANK you for having added much to this that otherwise would have been overlooked. And to feed back some answers as to my original intent. 1. Yes- Explicit in the concept is *NOT* having the Operating system on a drive holding the "Non-OS" data The reasons why are several. Your comment about which OS can share which file system does cause a reconsideration of how other details interact. The other comment of yours about USB drives raises an interesting script question- scripting a "write current differences" to the "local" portable drive. As in - a scripted routine that updates my thumbdrive to mirror the fixed image of "my" data. If I understand the Wiki site writeup on Andrew- it would manage the revisions difference between my portable drive and the fixed share a bit better than other ways. Is my understanding correct? -- Oren Beck 816.729.3645
On Thu, Apr 3, 2008 at 3:01 PM, David Nicol <davidnicol@gmail.com> wrote:
On Thu, Apr 3, 2008 at 2:52 PM, Geoffrion, Ron P [IT] <Ron.Geoffrion@sprint.com> wrote:
The result is a "one user data library - OS Agnostic to the computer accessing it model.
Not likely.
done every day, for decades. Client/server, tiered architectures do exactly this.
As the original, small-disk best practices of keeping data on /var or /var/spool or wherever. With the newer vast hard drives, we've gotten sloppy to the point of forgetting that it was not ever thus.
Distributed file systems -- andrew file system, etc -- designed to keep your valuable data in the secure and robust organizational central store so you don't have to worry about which machine you use in the lab or if your laptop gets stolen -- it's all been done.
-- bringing useful insights from Computer Science to the larger world
Good addition to the concept! Andrew files system: http://en.wikipedia.org/wiki/Andrew_file_system Is a potential winner in the SFT clone I am trying to figure out how to put together. As for the OS on a separate drive project- What do you suggest as the desired final File system choice ? -- Oren Beck 816.729.3645
On Thu, Apr 3, 2008 at 2:43 PM, Oren Beck <orenbeck@gmail.com> wrote:
I'd like to think KCLUG could do better..
Oren, I'm getting tired of all of these little proposals. KCLUG is a lot of things to a lot of people, but it is not, and I realize I am taking on a tone I don't like to see, a linux distribution and promotion company with resources to allocate to product concepts. Why don't you take the time to research and implement one or two of the ideas you have? This applies to the "make it didn't happen" multi-session backup liveCD you've been talking about for years as much as your new HA proposals. I would like to see a change in tone from "Here's yet another daydream I just had that I would like to share" to "While I was working on project P, which I have started, I got stuck on not being able to framulate the frizblishizbit with full frastulation -- how do I enable full frastulation in a partially framulated frizblishizbit?" Then, the helpful and experienced framulators of frizblishizbits will cheerfully de-lurk and share their stories, and everyone is happy. Can you do that for us? I'd like to think that Oren Beck can do better. -- bringing useful insights from Computer Science to the larger world
On Thu, Apr 3, 2008 at 2:56 PM, David Nicol <davidnicol@gmail.com> wrote:
On Thu, Apr 3, 2008 at 2:43 PM, Oren Beck <orenbeck@gmail.com> wrote:
I'd like to think KCLUG could do better..
Oren, I'm getting tired of all of these little proposals. KCLUG is a lot of things to a lot of people, but it is not, and I realize I am taking on a tone I don't like to see, a linux distribution and promotion company with resources to allocate to product concepts.
Why don't you take the time to research and implement one or two of the ideas you have? This applies to the "make it didn't happen" multi-session backup liveCD you've been talking about for years as much as your new HA proposals.
I would like to see a change in tone from "Here's yet another daydream I just had that I would like to share" to "While I was working on project P, which I have started, I got stuck on not being able to framulate the frizblishizbit with full frastulation -- how do I enable full frastulation in a partially framulated frizblishizbit?"
Then, the helpful and experienced framulators of frizblishizbits will cheerfully de-lurk and share their stories, and everyone is happy.
Can you do that for us?
I'd like to think that Oren Beck can do better.
-- bringing useful insights from Computer Science to the larger world
_______________________________________________
Ok sir- your well meaning Comments re: daydreams have dictated I unbag a cat that was scripted for later release. Craig, who is on staff at the campground recently did a variant of my proposal. And he did it all unassisted. He moved his older Ubuntu drive to secondary ,installed a new drive. . Then installed Ubuntu 7.10 on the new master drive. And found his old "user data" on the old drive was all seamlessly accessible. Thus showing that a contemporary Linux distro can seamlessly functrion with the "user data" on a second drive. So what? is the next snarky potential jeer someone could toss at me The pre-empting comment is - Who here can detail their take on the optimal partitioning and file layout to do this on a second disk not needfully having an OS on it. Oh yes, in comment back on the potentially Ad Hominem zone of Daydreams and project requests as opposed to what I did reports.. Considering the past detours this list has taken from Linux and Open Source - The majority of my posts/comments were and are "on topic" Or otherwise still in the general good direciton. And this one seems to have sparked a few REALLY good constructive comments on the Linux file partition naming convention details. The context of someone explaining the how and why of file conventions does more to educate us all BY that context of question raised and answered. Bluntly put- the joy of trying to refute a statement can also produce sincere value in education of others. I made a malaprop in the use of /usr as example that I should have said "named_user_data_folders" for descriptive label. I appreciate a constructive correction! Look at the rest like this- KCLUG has a literally incredible pool of talents-yourself included David. I may have tripped some loose hair of yours by perceives whatever. I will by default accept your comments as constructive and ask only the same in return. No harm no foul in either direction ok? The larger reason for some of my comments is NOT an ego wanting "my" name on a damned thing. It's all about hoping some others in this group can show us their chops and all of us LEARN from it! I may be guilty as many of us are for other foibles and diversions both at the meetings and on list, Yet I must categorically state the fact of my intent as being an unselfish "let's see what WE can do. Hell- some of us could have arguably been zillionaires had we Gone Evil eh? And i do mean SEVERAL group members! The closing back on topic comment is? A Linux users group should do things to foster the daily USE of Linux. -- Oren Beck 816.729.3645
On Thu, Apr 3, 2008 at 4:14 PM, Oren Beck <orenbeck@gmail.com> wrote:
Ok sir- your well meaning Comments re: daydreams have dictated I unbag a cat that was scripted for later release.
LOL are you really Steve Nordquist hiding under a pseudonym? Jeffrey. -- "He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself." -- Thomas Paine
On Thu, Apr 3, 2008 at 2:43 PM, Oren Beck <orenbeck@gmail.com> wrote:
This is a request for comment on a basic hardware and software assignment method.
The simplest minimal applied version would be master drive OS and slave drive bearing data.
The next higher levels would include replicated data drives. Not needfully in the same machine or even at the same site.
I'd like to propose a Request for Comments where we talk about moving from a bus-specific input device specification (AT and PS2 for keyboards, and PS2 for mice) to a more device generic input bus model (USB for both). I'd think that the folks in KCLUG can come up with some really interesting discussion with regards to multi-input device bus channels in the modern PC under recent distributions of Linux. For example: * In doing away with input device specific data input channels, do we benefit from decreasing the physical peripheral input hardware footprint on the real computing device? * Does this translate into optimal efficiency at the filesystem level by negating the necessity of files in the pseudo-device directory hierarchy such as /dev/psaux? * Does a single specification for hardware peripheral data input methods like USB open up possibilities like daisy chaining physical input methodologies into discrete time-ordered functional equivalents in a data centric computing environment? For example, allowing a non-interrupt driven means of obtaining non-keyboard/mouse input in the form of webcams, scanners, and the like? * If device input methodologies are consolidated into a single specification, can we do innovative things like plug our mouse into the other end of our keyboard, and then plug the entire keyboard/mouse user input device into a single physical port on our computing system? Discuss! -- Chris
participants (7)
-
Brian Kelsay -
Christofer C. Bell -
David Nicol -
Geoffrion, Ron P [IT] -
Jeffrey Watts -
Luke -Jr -
Oren Beck