Does the 'professional' side, Suse Corporate support, see this sort of thing? Do these problems beset the industrial/commercial of BtrFS? If we were dealing with a pre-computer item that number of problems, problems with user management, then there would be serious questions about its design. Some things we deemed 'over-engineered'. In latter-day terms they weren't "user-friendly' as they needed a maintenance technician constantly at had. I'm sure some of us can recall a few classic IBM goofs of that nature. By contrast we have a few very boring file systems. We deem them 'out of support' because no-one wants to work on them. Or perhaps the designers got them right the first time. At one level it comes down to economics. With the over-egged system the vendor can charge the customers for ongoing support. The downside is that the vendor is better off it the support doesn't have to be carried out. And there's an even bigger downside if the customer has alternatives. IBM and Microsoft found that out. Both their solutions were similar: build systems that are *reliable* and *easy* for the customer to manage and maintain himself. Easy meaning that 'answers' to operational questions are obvious. The problems that IBM faced, that M$ faces, is cost & inflexibility. Right now, those are the great advantages of Linux. Well actually both are deceptive. There are hidden costs (like the need to have all this ongoing maintenance with the FS that Suse recommends (and note that RedHat doesn't). And, given what CompSci research has achieved over the last quarter century, the still-monolithic CPU-bound process model that Linux (and the other UNIX derivatives) perpetuates and propagates, isn't that flexible. But my main question is about whether or not the corporate side of Suse , its customers, have these problems with BtrFS as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org