[opensuse] BTRFS barfed up my filesystem
Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off). Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode. So I boot up with an install CD in recovery mode, run a btrfs check, and get a screen scroll of over 2500 files with reference counters of zero. The system will boot, but locks up shortly there after, and often with a watch dog timer indicating that one or the other of the CPUs locked up. (sometimes 0, sometimes 1). I can't seem to find any Google foo to repair that file system, so tomorrow I will nuke the thing, reinstall (I'm done with BTRFS, I never saw any benefit from it) and restoring from backups which I took just before vacation. This is the third time BTRFS crapped all over my machine and it seems very fragile to me while providing very little benefit, and a whole lot of ambiguity as far as disk usage, free space and the recover options seem pathetically immature. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/2015 10:51 PM, John M Andersen wrote:
I can't seem to find any Google foo to repair that file system, so tomorrow I will nuke the thing, reinstall (I'm done with BTRFS, I never saw any benefit from it) and restoring from backups which I took just before vacation.
JA, I think Anton is the resident expert on BTRFS barfing. IIRC, he had a very similar story that included bolded **Warning: data loss occurred** (or something to that effect). See if you can raise him. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/02/2015 05:51 AM, John M Andersen wrote:
Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off).
Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode.
I don't use BTRFS, so here's a hint in another direction: Can you rule out a disc/hardware issue? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/2/2015 2:19 AM, Bernhard Voelker wrote:
On 04/02/2015 05:51 AM, John M Andersen wrote:
Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off).
Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode.
I don't use BTRFS, so here's a hint in another direction:
Can you rule out a disc/hardware issue?
Have a nice day, Berny
Smart shows the drive to be perfect, (it is essentially new), its never had any tracks remapped, or any indication of failure or pre-failure. There are, as I've mentioned, been several panics based on watchdog timer detecting that one processor had a hard locked up. Turns out when you look into that, the problem is common, and has been patched, but apparently that has not been fixed on OpenSuse. I never get these panics on a 3.16.6-2. (Came on the DVD) I frequently get the panic on 3.16.7-7. Google this phrase: "Kernel panic - not syncing: Watchdog detected hard" It has a lot of hits in a lot of different distros. I'm prepared to accept the fact that the panic has corrupted the BTRFS file system but since BTRFS has no tools to repair a corruption I'm going to have to re-install, because it won't run long enough to perform any kind of restore. Its been an interesting experiment, but if any little thing goes wrong, you are toast with btrfs. I've had (on other hardware) panics on other file systems and never lost any data. If we designed buildings this fragile, the first damn woodpecker to come along would destroy civilization. (This is opensuse 13.2 from a fresh install). -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/02/2015 10:58 AM, John Andersen wrote:
On 4/2/2015 2:19 AM, Bernhard Voelker wrote:
On 04/02/2015 05:51 AM, John M Andersen wrote:
Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off).
Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode.
I don't use BTRFS, so here's a hint in another direction:
Can you rule out a disc/hardware issue?
Have a nice day, Berny
Smart shows the drive to be perfect, (it is essentially new), its never had any tracks remapped, or any indication of failure or pre-failure.
There are, as I've mentioned, been several panics based on watchdog timer detecting that one processor had a hard locked up. Turns out when you look into that, the problem is common, and has been patched, but apparently that has not been fixed on OpenSuse. I never get these panics on a 3.16.6-2. (Came on the DVD) I frequently get the panic on 3.16.7-7.
Google this phrase: "Kernel panic - not syncing: Watchdog detected hard" It has a lot of hits in a lot of different distros.
I'm prepared to accept the fact that the panic has corrupted the BTRFS file system but since BTRFS has no tools to repair a corruption I'm going to have to re-install, because it won't run long enough to perform any kind of restore.
Its been an interesting experiment, but if any little thing goes wrong, you are toast with btrfs. I've had (on other hardware) panics on other file systems and never lost any data. If we designed buildings this fragile, the first damn woodpecker to come along would destroy civilization.
(This is opensuse 13.2 from a fresh install).
John, I posted in another thread that I was able to backup my btrfs file system to a USB drive, take that drive to another identical system, load the system there and boot it. So backups are possible with btrfs. I just run on a laptops (rather big ones) so have not been impressed with the requirements for the snapshots, and have them disabled them on my systems. In another entry I was described as "Joe Sixpack Linux users that are dazed by these new concepts". But I now have backups, and have not had other problems with btrfs. There seems to be a desire to always reinvent the wheel, KISS is dead:-) I can give more details on how I do my backup if desired. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/06/2015 10:14 AM, jdd wrote:
Le 06/04/2015 19:11, don fisher a écrit :
I can give more details on how I do my backup if desired.
I could take it, thanks!
jdd
My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option. I had helpful emails from many members of the list, but I will not include their names to avoid their incrimination. First I installed an openSuse 13.2 system on my 500GB USB drive. I figured that installing openSuse would establish the btrfs, the correct /boot entries for that drive, along with the correct volume IDs in fstab. These entries are exclude form overwrite in the attached excludes file. I then mounted the USB / and /home partitions, on my system at /mnt/usr11 and /mnt/usr12. These are the first two entries in the attached script, commented out because for now, I do them by hand. I then did an rsync from primary / to / on the USB drive, and from primary /home to the /home on the USB drive. The two rsync commands in the included file are different because I desired an exact copy, and rsync normally pays attention to file creation dates. But if the openSuse system on the USB drive was created after the one on my primary system, files there could have later dates and not be updated. Therefore I used the -c switch to rsync telling it to match checksums (on the rsync command target for the root directory). I let rsync in the /home partition match dates to avoid needless computation of checksums. I have also attached my excludes file. There may be more probably in /var, that could be excluded. But so far this works. When the system boots I assumed that it would overwrite any files present that it does not require. My background is as an EE, spent most of my time in image processing, real time applications and assembler code. So please forgive any glaring errors in formats. Never took a computer science course:-( Suggestions for improvements would be appreciated. (Also, the dot at the start of my excludes file name is missing, Thunderbird would not show the . files to allow their attachment :-) Don
Le 06/04/2015 20:45, don fisher a écrit :
My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option.
it's valid, but not simple :-( Just a detail, I got the feeling that your backup drive was bootable in p)lace of the old one, is this true? or is it necessary to restore the system in case of failure? because in the latter case there are solution using less volume on disk (like using the rpm database to rebuild the distribution and only backup the config folders. I also have some questions about database and web applications, but I guess you don't have a web server on this computer :-). I would like to have only to copy the /etc folder to keep the config, but part of it is not in this folder, some being in the database (in /var), some other in htdocs, some other who knows where :-). also I think you had questions about btrfs subvolumes, I didn't read an answer thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/06/2015 02:10 PM, jdd wrote:
Le 06/04/2015 20:45, don fisher a écrit :
My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option.
it's valid, but not simple :-(
Just a detail, I got the feeling that your backup drive was bootable in p)lace of the old one, is this true? or is it necessary to restore the system in case of failure?
because in the latter case there are solution using less volume on disk (like using the rpm database to rebuild the distribution and only backup the config folders.
I also have some questions about database and web applications, but I guess you don't have a web server on this computer :-).
I would like to have only to copy the /etc folder to keep the config, but part of it is not in this folder, some being in the database (in /var), some other in htdocs, some other who knows where :-).
also I think you had questions about btrfs subvolumes, I didn't read an answer
thanks jdd
I made my USB drive bootable. If the machine died I wanted to be able to boot the USB drive and restore the system. Tell me more about the RPM database. I assumed the existence of, but did not search out, a place where a record of all of the packages existing on my system were stored. Please tell me were it is. USB drive are almost free now, so I didn't care about the space it required to make my backup. I do not recall the questions about btrfs subvolumes. It was pointed out to me that there were two ways of looking at the volume, via / and via the subvolums. btrfs puts the data in the correct subvolumes if the data is written to root. So I basically ignore the subvolumes. As far as I can tell there purpose is to isolate sections of the filesystem so that snapshots will work, but I have them disabled anyway. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 07/04/2015 00:51, don fisher a écrit :
I made my USB drive bootable.
I don't' see this in the script, so the question. How do you do this? If the machine died I wanted to be able to
boot the USB drive and restore the system.
yes, very good option! Tell me more about the RPM
database. I assumed the existence of, but did not search out,
https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_rpm.html say: The files of the RPM database are placed in /var/lib/rpm. If the partition /usr has a size of 1 GB, this database can occupy nearly 30 MB, especially after a complete update. a place
where a record of all of the packages existing on my system were stored. Please tell me were it is. USB drive are almost free now, so I didn't care about the space it required to make my backup.
for the system, ok, but for the data... but if the system is restored, pne can restore the data anyway thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/06/2015 02:45 PM, don fisher wrote:
My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option.
I've never done EXACTLY that, but what I have done is taken a listing of what's in the RPM database, the list of all the packages installed on a machine and their revisions, edited, and then used it, with a suitable script processing each line, to install "all" (well most) the packages on another machine. Rather than copy, I made the repositories do the hard work. Back then I had copious (employer supplied) bandwidth. At home, paying, I would install from CD and do another dump of the RPM database and diff to see what I would have to add and only process that. The RPM database is a wondrous thing and I find I peer into it for various purposes quite often. Today, for example, I looked to see what OTHER binaries/runables and external optional modules came with a package. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 01 Apr 2015 08:51:30 PM CDT, John M Andersen wrote:
This is the third time BTRFS crapped all over my machine and it seems very fragile to me while providing very little benefit, and a whole lot of ambiguity as far as disk usage, free space and the recover options seem pathetically immature. Hi Sounds very much like a hardware issue rather than a filesystem issue if it's happened multiple times with the same hardware....
RAM, disk all ok? -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.38-44-default up 0:15, 3 users, load average: 0.11, 0.15, 0.22 CPU AMD A4-5150M APU @ 3.3GHz | GPU Richland Radeon HD 8350G -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/01/2015 11:51 PM, John M Andersen wrote:
Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off).
Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode. So I boot up with an install CD in recovery mode, run a btrfs check, and get a screen scroll of over 2500 files with reference counters of zero.
The system will boot, but locks up shortly there after, and often with a watch dog timer indicating that one or the other of the CPUs locked up. (sometimes 0, sometimes 1).
I can't seem to find any Google foo to repair that file system, so tomorrow I will nuke the thing, reinstall (I'm done with BTRFS, I never saw any benefit from it) and restoring from backups which I took just before vacation.
This is the third time BTRFS crapped all over my machine and it seems very fragile to me while providing very little benefit, and a whole lot of ambiguity as far as disk usage, free space and the recover options seem pathetically immature.
I'm far from an expert in BtrFS, just a user, who has, at times, had to play closer than normal attention. Try Chris Murphy. What you described happened to me a long time ago, many revisions age. You don't' say which version of the kernel you use, BtrFS + Tools. Its in constant revision and along the way there have been ... Diversions ... That have been less than satisfactory. I suppose one might say that one should never turn off the machine :-) Certainly every problem I've ever had has involved turning the machine back on :-) What? Disk crash from head retraction? BTDT a couple of times :-( When this happened to me it was on a /home partition. I've never had it happen on a ROOT partition. Not even at the time I was also running the BtrFS-ificated /home. I did speculate that the BtrFS driver was not re-entrant, but was told that is not so. So, what benefit is there to BtrFS other than its new and shiny? My interest in it was to avoid the fixed number of inodes situation with ext4. I'd been bitten by that to many times in the last century and this. I had been using ReiserFS and was happy with that but people keep telling me its unsupported and won't be around. ZFS is getting to look viable and does what BtrFS claims, volume management, spindle management over and above the simple partition model. Its reputed to be one of the really good things that came out of SUN. I can believe that. Is it production ready for Linux yet? I can't speak to that. Linda recommends XFS. It seems very fiddly to me. In the long run I wouldn't give up on BtrFS. KDE4 was a true Open Source project in that it was a 'ship early and get feedback' project. The mistake was that the early version were treated as production not as development. It was released as part of the main system, replacing KDE3 completely, before it was ready. Yes, it forced users to try it out, push its limits and report bugs. Perhaps if it hadn't been forced on us its development would have been slower. Perhaps too there would have been less antagonism. BtrFS seems to have gone the same way, forced on us, and without a lot of consideration about such matters as "whole disk" vs partition, an issue which is key to the design assumptions; without adequate explanation of 'snapper'; without adequate explanation of subvolumes. All of these are new concepts. The questions that Don Fisher has posed are indicative, I think, of how the Joe Sixpack Linux users are dazed by these new concepts. I'm not sure how to handle them so have them all disabled. Linda recommends XFS. Personally I find it too fiddly. And there's JFS out of Veritas and IBM. I don't know anything about that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/2/2015 4:04 PM, Anton Aylward wrote:
Linda recommends XFS. Personally I find it too fiddly.
I still have machines running reiserfs. I've had it crash, once years ago, but never lost any data. When btrfs died I lost data to the point where it wouldn't run. But because it was basically just the OS, (and a few unfortunately placed scripts) I was able to just reinstall and get it all back from backups that I keep on my NAS. Because I wanted encryption, I went with xfs for /home and one other critical partition that I use for source code. Those two partitions were not affected, only my btrfs / (root) and all of it's subvolumes. So I nuked only that btrfs root partition and went back to ext4, retaining my xfs partitions. I haven't found anything to fiddle with xfs nor any reason to fiddle with it. Its what I had, so I kept it. With BTRFS I was never sure how much room/free space I had available, how many snapshots I should keep, etc. I never understood why they chose to implement so many sub-directories of root as sub-volumes, when all those sub-volumes were drawing on the same free space pool! I'm letting it mature and letting the tool set mature so that Joe User has a chance of understanding what is going on, or it gets to the state of Reiserfs where you just don't have to worry about it. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/02/2015 07:12 PM, John Andersen wrote:
With BTRFS I was never sure how much room/free space I had available, how many snapshots I should keep, etc. I never understood why they chose to implement so many sub-directories of root as sub-volumes, when all those sub-volumes were drawing on the same free space pool!
I'm letting it mature and letting the tool set mature so that Joe User has a chance of understanding what is going on, or it gets to the state of Reiserfs where you just don't have to worry about it.
That is precisely what a filesystem should do/provide. It's just something that is there, that does it's job, that the user never revisits after creating it. (except for fsck....) Over the course of the past 16 - 17 years, I have lost many many disks, but never data due to a filesystem failure or error. I count at least a handful of BTRFS failures discussed on the list in the past 6 months or so. BTRFS may end up being the next best thing since sliced bread, but currently it seams the loaf is not quite yet done for production environments. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
BTRFS may end up being the next best thing since sliced bread, but currently it seams the loaf is not quite yet done for production environments. Still I give credit to Opensuse for integrating it into their install
On 4/2/2015 7:15 PM, David C. Rankin wrote: process and partition setup. They make it really easy to set it up. Unfortunately, filing a bug report on BTRFS is sort of difficult when your system won't even boot, and you can't get your logs, or anything in the way of diagnostics. So we talk about it on this list, but nothing concrete gets sent up to the developers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-03 04:15, David C. Rankin wrote:
Over the course of the past 16 - 17 years, I have lost many many disks, but never data due to a filesystem failure or error.
I had corrupted partitions with all filesystem types. Unrecoverable. ext3, reiserfs, xfs... You just have to hit on the wrong nail. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUiap0ACgkQja8UbcUWM1wkFwEAkioqYuttWACpXXw/WQBg7RvH rH8aAyGPp9E0RvkHLfUA/ikguz8DbYcv+OZfh5nRgO8z6ulOJDTmJ8dGLvkDE0mH =608o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/02/2015 08:12 PM, John Andersen wrote:
On 4/2/2015 4:04 PM, Anton Aylward wrote:
Linda recommends XFS. Personally I find it too fiddly.
I still have machines running reiserfs. I've had it crash, once years ago, but never lost any data.
Same here. If I knew anything about FS programming I'd volunteer to maintain it :-) Its been remarkably rock solid; the programmers were damn god. The BtrFS bunch could learn from whatever magical prestidigitation the crew there in Russia practised.
Because I wanted encryption, I went with xfs for /home and one other critical partition that I use for source code.
Regular readers will recall that I advocate LVM. One reason I'm not fanaticial about the ability of BtrFS to take over the whole File tree and spread across spindles. So if I want encryption I do it with LVM and the device mapper http://cryptmount.sourceforge.net/ http://sourceware.org/dm/
I haven't found anything to fiddle with xfs nor any reason to fiddle with it. Its what I had, so I kept it.
Ah, you use 'fiddle' where I would use 'tweak'. I'm referring to all the components. By comparison, Reiser and ext4 are straight forward. I don't mean "knobs to tweak' as in setting to to adjust/tune. The package 'xfsprogs' has 23 separate programs (including the mkfs and fsck), components, for doing things with XFS. By comparison Reiser has 5. Well maybe those XFS components _are_ for tweaking.
With BTRFS I was never sure how much room/free space I had available, how many snapshots I should keep, etc. I never understood why they chose to implement so many sub-directories of root as sub-volumes, when all those sub-volumes were drawing on the same free space pool!
I have the same questions. Particularly the ones about sub-volumes ~=~ sub-directories It makes no sense to me.
I'm letting it mature and letting the tool set mature so that Joe User has a chance of understanding what is going on, or it gets to the state of Reiserfs where you just don't have to worry about it.
+1 -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 4/2/2015 8:10 PM, Anton Aylward wrote:
the programmers were damn god.
And at least one was damned by god, as well as the State of California. Ultimately, Reiser's problems were visited upon the software. And even though Opensuse was the principal maintainer, it never survived. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/04/15 01:12, John Andersen wrote:
With BTRFS I was never sure how much room/free space I had available, how many snapshots I should keep, etc. I never understood why they chose to implement so many sub-directories of root as sub-volumes, when all those sub-volumes were drawing on the same free space pool!
A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot. I am not a btfrs expert, but have used it here for the past 9 months without any problems (so far!) Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUeULcACgkQ0Sr7eZJrmU6biQCeOib6lNOUJXa1wm0i6RNElRA3 +fMAnA1PusZYmtqQZkdeqRUTChdeFdVM =h7mc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/2015 04:35 AM, Bob Williams wrote:
A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot.
If we take the scenario where instead of the sub-volumes we have mount points and mountable file systems -- a more 'traditional' (and understandable) approach -- then there is an iso-morphism here. The snapshot doesn't cover the file systems mounted because they are different file systems. "Res ipse loquitur" The only difference is that in the total BtrFS case its all the one physical space. Since, as I've commented before, BtrFS is conceived as being the who system, this all makes sense. Now I run BtrFS as the root FS, took away the sub-volumes mentioned and have them as mounted file systems. All this is done on a backdrop of LVM. I can snapshot any file system using LVM. If ReiserFS had a long term future I wouldn't even be considering BtrFS for other than SSD. As it is, I feel trapped into a future where I have to use BtrFS (to avoid the fixed inode idiocy that has existed ever since the V6/7 FS for UNIX of the 1970s) and all the complexity, and the problems that goes with complexity, of the grand Design outlook of BtrFS. The idiea of having separate volume management and file systems appeals to me. Heck, with LVM I can even use (or if you prefer, 'experiment') with other file systems (including BtrFS as a file system!). In effect LVM is a platform that does for filesystems what the virtualization tools do for operating systems. Integrating the volume management and the file system all into one, as with BtrFS, removes that flexibility. -- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I've been using btrfs for "/" and "/home" for months with zero problems, aside from a kernel bug that showed up when I plugged in an external HD that froze my PC which has been patched. What's the advantage to using XFS for /home? I haven't touched XFS for years, but never had any problems with it. I thought XFS performance was bad on small files. On Fri, Apr 3, 2015 at 5:16 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/03/2015 04:35 AM, Bob Williams wrote:
A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot.
If we take the scenario where instead of the sub-volumes we have mount points and mountable file systems -- a more 'traditional' (and understandable) approach -- then there is an iso-morphism here. The snapshot doesn't cover the file systems mounted because they are different file systems. "Res ipse loquitur"
The only difference is that in the total BtrFS case its all the one physical space. Since, as I've commented before, BtrFS is conceived as being the who system, this all makes sense.
Now I run BtrFS as the root FS, took away the sub-volumes mentioned and have them as mounted file systems. All this is done on a backdrop of LVM. I can snapshot any file system using LVM.
If ReiserFS had a long term future I wouldn't even be considering BtrFS for other than SSD.
As it is, I feel trapped into a future where I have to use BtrFS (to avoid the fixed inode idiocy that has existed ever since the V6/7 FS for UNIX of the 1970s) and all the complexity, and the problems that goes with complexity, of the grand Design outlook of BtrFS.
The idiea of having separate volume management and file systems appeals to me.
Heck, with LVM I can even use (or if you prefer, 'experiment') with other file systems (including BtrFS as a file system!). In effect LVM is a platform that does for filesystems what the virtualization tools do for operating systems.
Integrating the volume management and the file system all into one, as with BtrFS, removes that flexibility.
-- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On April 4, 2015 1:45:04 PM PDT, "Sam M." <backgroundprocess@gmail.com> wrote:
I've been using btrfs for "/" and "/home" for months with zero problems, aside from a kernel bug that showed up when I plugged in an external HD that froze my PC which has been patched. What's the advantage to using XFS for /home? I haven't touched XFS for years, but never had any problems with it. I thought XFS performance was bad on small files.
On Fri, Apr 3, 2015 at 5:16 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/03/2015 04:35 AM, Bob Williams wrote:
A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot.
If we take the scenario where instead of the sub-volumes we have mount points and mountable file systems -- a more 'traditional' (and understandable) approach -- then there is an iso-morphism here. The snapshot doesn't cover the file systems mounted because they are different file systems. "Res ipse loquitur"
The only difference is that in the total BtrFS case its all the one physical space. Since, as I've commented before, BtrFS is conceived as being the who system, this all makes sense.
Now I run BtrFS as the root FS, took away the sub-volumes mentioned and have them as mounted file systems. All this is done on a backdrop of LVM. I can snapshot any file system using LVM.
If ReiserFS had a long term future I wouldn't even be considering BtrFS for other than SSD.
As it is, I feel trapped into a future where I have to use BtrFS (to avoid the fixed inode idiocy that has existed ever since the V6/7 FS for UNIX of the 1970s) and all the complexity, and the problems that goes with complexity, of the grand Design outlook of BtrFS.
The idiea of having separate volume management and file systems appeals to me.
Heck, with LVM I can even use (or if you prefer, 'experiment') with other file systems (including BtrFS as a file system!). In effect LVM is a platform that does for filesystems what the virtualization tools do for operating systems.
Integrating the volume management and the file system all into one, as with BtrFS, removes that flexibility.
-- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
My home is a mix of small files an very huge ones, big virtual machine files, largish images etc. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 02 April 2015 19:04:56 Anton Aylward wrote:
What you described happened to me a long time ago, many revisions age. You don't' say which version of the kernel you use, BtrFS + Tools. Its in constant revision and along the way there have been ... Diversions ... That have been less than satisfactory.
I suppose one might say that one should never turn off the machine :-) Certainly every problem I've ever had has involved turning the machine back on :-) What? Disk crash from head retraction? BTDT a couple of times :-(
When this happened to me it was on a /home partition. I've never had it happen on a ROOT partition. Not even at the time I was also running the BtrFS-ificated /home. I did speculate that the BtrFS driver was not re-entrant, but was told that is not so.
So, what benefit is there to BtrFS other than its new and shiny?
My interest in it was to avoid the fixed number of inodes situation with ext4. I'd been bitten by that to many times in the last century and this. I had been using ReiserFS and was happy with that but people keep telling me its unsupported and won't be around.
ZFS is getting to look viable and does what BtrFS claims, volume management, spindle management over and above the simple partition model. Its reputed to be one of the really good things that came out of SUN. I can believe that. Is it production ready for Linux yet? I can't speak to that.
Linda recommends XFS. It seems very fiddly to me.
In the long run I wouldn't give up on BtrFS. KDE4 was a true Open Source project in that it was a 'ship early and get feedback' project. The mistake was that the early version were treated as production not as development. It was released as part of the main system, replacing KDE3 completely, before it was ready. Yes, it forced users to try it out, push its limits and report bugs. Perhaps if it hadn't been forced on us its development would have been slower. Perhaps too there would have been less antagonism.
BtrFS seems to have gone the same way, forced on us, and without a lot of consideration about such matters as "whole disk" vs partition, an issue which is key to the design assumptions; without adequate explanation of 'snapper'; without adequate explanation of subvolumes. All of these are new concepts. The questions that Don Fisher has posed are indicative, I think, of how the Joe Sixpack Linux users are dazed by these new concepts. I'm not sure how to handle them so have them all disabled.
Linda recommends XFS. Personally I find it too fiddly.
And there's JFS out of Veritas and IBM. I don't know anything about that.
Interesting summary, makes a lot of sense. And repetition of Linda and her XFS makes it little psychodelic :) For me btrfs works quite good so far, except for USB 3.0 SSD drive, where it constantly loses free space cache, which in turn hangs the systemd for all the eternity on umount and I have to use hard poweroff. At first I was using clear_cache mount option as default, but couple of days ago gave up and reformatted everything to ext4. At least it does not have the same issues. On the other hand, I've set btrfs on encrypted /home despite yast not allowing that. Was not so hard actually, and works much much better then XFS. And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time. That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all. -- Regards, Stas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 02 April 2015 19:04:56 Anton Aylward wrote:
What you described happened to me a long time ago, many revisions age. You don't' say which version of the kernel you use, BtrFS + Tools. Its in constant revision and along the way there have been ... Diversions ... That have been less than satisfactory.
I suppose one might say that one should never turn off the machine :-) Certainly every problem I've ever had has involved turning the machine back on :-) What? Disk crash from head retraction? BTDT a couple of times :-(
When this happened to me it was on a /home partition. I've never had it happen on a ROOT partition. Not even at the time I was also running the BtrFS-ificated /home. I did speculate that the BtrFS driver was not re-entrant, but was told that is not so.
So, what benefit is there to BtrFS other than its new and shiny?
My interest in it was to avoid the fixed number of inodes situation with ext4. I'd been bitten by that to many times in the last century and this. I had been using ReiserFS and was happy with that but people keep telling me its unsupported and won't be around.
ZFS is getting to look viable and does what BtrFS claims, volume management, spindle management over and above the simple partition model. Its reputed to be one of the really good things that came out of SUN. I can believe that. Is it production ready for Linux yet? I can't speak to that.
Linda recommends XFS. It seems very fiddly to me.
In the long run I wouldn't give up on BtrFS. KDE4 was a true Open Source project in that it was a 'ship early and get feedback' project. The mistake was that the early version were treated as production not as development. It was released as part of the main system, replacing KDE3 completely, before it was ready. Yes, it forced users to try it out, push its limits and report bugs. Perhaps if it hadn't been forced on us its development would have been slower. Perhaps too there would have been less antagonism.
BtrFS seems to have gone the same way, forced on us, and without a lot of consideration about such matters as "whole disk" vs partition, an issue which is key to the design assumptions; without adequate explanation of 'snapper'; without adequate explanation of subvolumes. All of these are new concepts. The questions that Don Fisher has posed are indicative, I think, of how the Joe Sixpack Linux users are dazed by these new concepts. I'm not sure how to handle them so have them all disabled.
Linda recommends XFS. Personally I find it too fiddly.
And there's JFS out of Veritas and IBM. I don't know anything about that.
Interesting summary, makes a lot of sense. And repetition of Linda and her XFS makes it little psychodelic :) For me btrfs works quite good so far, except for USB 3.0 SSD drive, where it constantly loses free space cache, which in turn hangs the systemd for all the eternity on umount and I have to use hard poweroff. At first I was using clear_cache mount option as default, but couple of days ago gave up and reformatted everything to ext4. At least it does not have the same issues. On the other hand, I've set btrfs on encrypted /home despite yast not allowing that. Was not so hard actually, and works much much better then XFS. And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time. That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all. -- Regards, Stas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/2015 11:32 AM, Stanislav Baiduzhyi wrote:
And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time.
That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all.
No need to cc me, I subscribe to the list ;-) I'm glad I'm not alone in my preference for ReiserFS :-) Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS? I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
With continual streaming of data to disks (similar to unpacking a big archive, but worse), I found that I needed to run the following in a system init script. # This clears cache related to the disk. Without this the cache grows and, it seems, bad # things happen... Don't know if 60 seconds between calls is best... while [ 1 ]; do echo 1 > /proc/sys/vm/drop_caches; sleep 60; done & Then things stay even. Even though the targets were XFS, IIRC the behavior was for all file systems. It is a kernel memory management thing. Seems continual data streaming to disk is not the typical usage scenario so things are not tuned that way. On Sun, Apr 5, 2015 at 4:54 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 04/03/2015 11:32 AM, Stanislav Baiduzhyi wrote:
And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time.
That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all.
No need to cc me, I subscribe to the list ;-)
I'm glad I'm not alone in my preference for ReiserFS :-)
Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS?
I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 11:23 AM, Roger Oberholtzer wrote:
With continual streaming of data to disks (similar to unpacking a big archive, but worse), .....
Seems continual data streaming to disk is not the typical usage scenario so things are not tuned that way.
Good point. This is why, for example, *some* database systems use the RAW disk rather than a file system. I also seem to recall there are some data streaming applications, video capture and the like, which do, or used to, at least in the days when equipment/CPU was a lot slower. But just unpacking archives? That's bursty. Unpack, compile ... Or are you doing something that is continuous unpacking and nothing else? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 05/04/2015 17:43, Anton Aylward a écrit :
But just unpacking archives? That's bursty. Unpack, compile ...
untaring achives largers than the available ram always was a problem for me... don't know exactly why jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 11:47 AM, jdd wrote:
Le 05/04/2015 17:43, Anton Aylward a écrit :
But just unpacking archives? That's bursty. Unpack, compile ...
untaring achives largers than the available ram always was a problem for me... don't know exactly why
Hmmm. "Use the source, Luke". It might depend on the algorithm. back in V7 days when there was no virtual memory and memory was short anyway, most algorithms were streaming and the use of pipes and filters with small programs tied together with shell scripts was the dominant style. Perhaps along the way, the GNU crowd have become lazy and tried to do in-memory processing. Which won't be good for, as you say, large archives. But with virtual memory surely the physical RAM isn't the issue? Please do elaborate. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-05 17:43, Anton Aylward wrote:
But just unpacking archives? That's bursty. Unpack, compile ... Or are you doing something that is continuous unpacking and nothing else?
The kernel can cache the entire unpack operation in RAM, and do the actual writing to disk later. XFS also uses RAM structures more than other filesystems. That delayed, intensive, write operation can tax heavily some computers more than normal. It happens to some people, that complain that even the mouse doesn't respond. Running a kernel build on a reiserfs partition runs faster than on ext3, by the way. Lots of small files are created. XFS has dynamic inodes: the number is not fixed at filesystem creation time. The btrfs people take ideas from XFS, they have some developers in common, IIRC. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUiciAACgkQja8UbcUWM1xrJwD/dICCfLZlEdo7vPpTOTx/CmuM luZkOZoMVK+3nDlkBWAA/R1hWBSVqgIsrPOzHMm7wcoa9r10OMhfNLwQHuMHr+fH =CEv4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Apr 05, 2015 at 10:54:47AM -0400, Anton Aylward wrote:
On 04/03/2015 11:32 AM, Stanislav Baiduzhyi wrote:
And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time.
That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all.
No need to cc me, I subscribe to the list ;-)
I'm glad I'm not alone in my preference for ReiserFS :-)
Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS?
I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is.
is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 11:33 AM, toothpik wrote:
I'm glad I'm not alone in my preference for ReiserFS :-)
Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS? I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is. is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...
I also used to use ReiserFS and was annoyed when development stopped. I currently use ext4 on my systems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-05 17:45, James Knott wrote:
On 04/05/2015 11:33 AM, toothpik wrote:
is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...
I also used to use ReiserFS and was annoyed when development stopped. I currently use ext4 on my systems.
Development never stopped. As far as I know, it continues, in the V4 tree. The V3 tree we use was integrated in the kernel, which for the reiserfs people meant that the maintenance was given over to the kernel people. They switched completely to work on V4. When Mr Reiser was imprisoned, the main driving force disappeared. Development continued, but slower. Years ago, SuSE implemented reiserfs ahead of other distros, before it was integrated into the kernel. They pushed its development a lot, but at a cost they do not want to incur into again. So we do have reiserfs 4 in an rpm somewhere in the distro, but it is not directly supported and people don't use it. Without support from a distribution, the very few people working on R4 have scarce a chance. And with the advent of btrfs, less. Pity. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUidRkACgkQja8UbcUWM1xZ8gEAic34vXoOmMcFM+N+DcXwIwKP k6iuxCrIj04RljAFc28A/itEETErVCdJ7058/DPY7vleEYHOA7oVLI9iZLLCFq9D =CQMd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 05/04/2015 17:33, toothpik a écrit :
is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...
I guess Reiser was kind of mad, like many genius are, I think Reiserfs 4 was never acheived (and one use the V3?) so may be the code is unmanageable. What I know is that I was a great lover of reiserfs :-) first time I demonstrated it in my Linux User Group, one of the member walking unplugged accidentally my computer and it rebooted without problem. Ancient ext2 users will understand :-) that said BTRFS seems the future and may be it's best like this... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 11:46 AM, jdd wrote:
first time I demonstrated it in my Linux User Group, one of the member walking unplugged accidentally my computer and it rebooted without problem. Ancient ext2 users will understand :-)
Many years ago, I was on a course for the Datapoint 2200. It had an 8008 CPU in discrete logic, as the Intel microprocessor was too slow. It had 16 Kb of dynamic RAM and two cassette desks for storage. In the class, I "accidentally" tripped over the power cord for another guy's system, before he had a chance to save his code. ;-) https://en.wikipedia.org/wiki/Datapoint_2200 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 08:53 AM, James Knott wrote:
On 04/05/2015 11:46 AM, jdd wrote:
first time I demonstrated it in my Linux User Group, one of the member walking unplugged accidentally my computer and it rebooted without problem. Ancient ext2 users will understand :-) Many years ago, I was on a course for the Datapoint 2200. It had an 8008 CPU in discrete logic, as the Intel microprocessor was too slow. It had 16 Kb of dynamic RAM and two cassette desks for storage. In the class, I "accidentally" tripped over the power cord for another guy's system, before he had a chance to save his code. ;-)
That's really cool! Those were the daze I was using HP-2100 and PDP-8/S minicomputers with ASR-33 teletypes. I still have a 2100 manual in my Closet of Horrors, anyone interested? To keep this on-topic, I also miss ReiserFS, and wonder what it would take to jump-start development? Remember when Tatu closed ssh? How long did it take for openSSH to fork and take over? openReiser? In recent years I've been using XFS which easily supports huge files and filesystems, but I still have some boxes running ReiserFS. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 12:27 PM, Lew Wolfgang wrote:
That's really cool! Those were the daze I was using HP-2100 and PDP-8/S minicomputers with ASR-33 teletypes.
At the time, I was working for CN Telecommunications, which was owned by Canadian National Railway. The 2200 was used as part of a system for tracking freight cars called "TRACS". In addition to the 2200, there was a couple of different models of printer, a card punch/reader, and serial interfaces. Some of the serial interfaces were used to send train lists to remote Teletype M28 printers and one used EBCDIC to an IBM mainframe in Montreal. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2015 11:33 AM, toothpik wrote:
is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...
Its not as if he was the sole programmer. Namesys - his company - had a number of developers active on the file system development. http://en.wikipedia.org/wiki/ReiserFS#Move_away_from_ReiserFS_to_ext3 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (16)
-
Anton Aylward -
Bernhard Voelker -
Bob Williams -
Carlos E. R. -
David C. Rankin -
don fisher -
James Knott -
jdd -
John Andersen -
John M Andersen
-
Lew Wolfgang -
Malcolm -
Roger Oberholtzer -
Sam M. -
Stanislav Baiduzhyi -
toothpik