[opensuse] no space left on the device
Hello, I was hit this morning by the "no space left on the device" symptom, probably related to BTRFS (?), when btrfs's df (znd normal df) gives at least half space free. To work I had to reinstall on the other disk a 13.2 version (with ext4, this time). I know it's a discussed problem, and I read many posts on the subject, but It still don't get how to solve it. I *can* login with the failsafe mode, as root (or not), CLI only, but any action that include temp file fails with "no space left on the device", yast segfault... I cleared /tmp and some files in /home with no change. Is it possible to recover this? how? thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 29 Apr 2015 04:06:35 PM CDT, jdd wrote:
Hello,
I was hit this morning by the "no space left on the device" symptom, probably related to BTRFS (?), when btrfs's df (znd normal df) gives at least half space free.
To work I had to reinstall on the other disk a 13.2 version (with ext4, this time).
I know it's a discussed problem, and I read many posts on the subject, but It still don't get how to solve it.
I *can* login with the failsafe mode, as root (or not), CLI only, but any action that include temp file fails with "no space left on the device", yast segfault...
I cleared /tmp and some files in /home with no change.
Is it possible to recover this? how?
thanks jdd Hi You need to delete snapshots....
What does the following show? btrfs fi usage / Have you adjusted the snapper config? -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.39-47-default up 18:54, 4 users, load average: 0.52, 0.27, 0.21 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
Le 29/04/2015 17:05, Malcolm a écrit :
You need to delete snapshots....
I guess it :-(
What does the following show?
btrfs fi usage /
from the oresent working config (new), problematic disk mounted on /mnt: # btrfs fi usage /mnt Overall: Device size: 40.00GiB Device allocated: 40.46GiB Device unallocated: 16.00EiB Used: 20.30GiB Free (Estimated): 19.70GiB (Max: 19.70GiB, min: 8.00EiB) Data to device ratio: 100 % Global reserve: 464.00MiB (used: 8.12MiB) Data,single: Size:38.24GiB, Used:18.98GiB /dev/sdb1 38.24GiB Metadata,single: Size:1.76GiB, Used:1.31GiB /dev/sdb1 1.76GiB System,single: Size:4.00MiB, Used:16.00KiB /dev/sdb1 4.00MiB Unallocated: /dev/sdb1 0.00B
Have you adjusted the snapper config?
well, how? thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 29 Apr 2015 05:24:35 PM CDT, jdd wrote:
Le 29/04/2015 17:05, Malcolm a écrit :
You need to delete snapshots....
I guess it :-(
What does the following show?
btrfs fi usage /
from the oresent working config (new), problematic disk mounted on /mnt:
# btrfs fi usage /mnt Overall: Device size: 40.00GiB Device allocated: 40.46GiB Device unallocated: 16.00EiB Used: 20.30GiB Free (Estimated): 19.70GiB (Max: 19.70GiB, min: 8.00EiB) Data to device ratio: 100 % Global reserve: 464.00MiB (used: 8.12MiB)
Data,single: Size:38.24GiB, Used:18.98GiB /dev/sdb1 38.24GiB
Metadata,single: Size:1.76GiB, Used:1.31GiB /dev/sdb1 1.76GiB
System,single: Size:4.00MiB, Used:16.00KiB /dev/sdb1 4.00MiB
Unallocated: /dev/sdb1 0.00B
Have you adjusted the snapper config?
well, how?
thanks jdd Hi Modify the /etc/snapper/configs/root file to set the number limit (I use 2 and 1) if timeline is enabled, I would disable.
What does the output show from; snapper list Have a read of this thread and the last post in the thread. https://forums.opensuse.org/showthread.php/502563-BTRFS-Root-file-system-siz... There is a balance script you can run; /usr/share/btrfsmaintenance/btrfs-balance.sh -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.39-47-default up 19:22, 4 users, load average: 0.10, 0.14, 0.20 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
Le 29/04/2015 17:41, Malcolm a écrit :
On Wed 29 Apr 2015 05:24:35 PM CDT, jdd wrote:
btrfs fi usage /
in fact, the most usable command is btrfs filesystem show that gives directly the disk as full the first info page I found was this one: http://www.nrtm.org/index.php/2012/03/13/the-joys-of-btrfs-and-opensuse-or-n... and one can notice than snapper delete accepts several snapshot numbers, so, snapper delete 150 151 152 163 168 deletes all the snapshots with the good number
Have you adjusted the snapper config?
I was thinking so :-(, I have TIMELINE_CREATE="no" no I have set: NUMBER_LIMIT="1" NUMBER_LIMIT_IMPORTANT="2" hope this will be better... the problem is that this bug let the computer on an unusable state, I have to install an other distro elsewhere to get a GUI, network and web browsing!! thanks for your help jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/29/2015 11:41 AM, Malcolm wrote:
There is a balance script you can run; /usr/share/btrfsmaintenance/btrfs-balance.sh
That reduced my use from 65% to 60%. I wonder if there is a problem with nearly-full BtrFS or with BtrFS that were once converted from ext3? -- Friends help you move. Real friends help you move bodies. -- 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-29 18:30, Anton Aylward wrote:
I wonder if there is a problem with nearly-full BtrFS or with BtrFS that were once converted from ext3?
I did a test some time ago (1..2 yrs), in which I filled a btrfs with small files till it exploded. Literally, crashed and had to be reformatted. There is a bugzilla on it. Other filesystem types simply stopped accepting new files, but did not corrupt. And reiserfs kept accepting files and files and files... no limit. At top speed, too. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVBKRIACgkQja8UbcUWM1wBnQEAnaJEAo3cUgGJ9VNZHvEh7AJP dg6GD0jfN/e/4QqRmYMBAINn/nR6QniWk09Uv8YfbO8Chj+CRBTrUX52KZBM5eNM =KBYz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 29 Apr 2015 12:30:34 PM CDT, Anton Aylward wrote:
On 04/29/2015 11:41 AM, Malcolm wrote:
There is a balance script you can run; /usr/share/btrfsmaintenance/btrfs-balance.sh
That reduced my use from 65% to 60%.
I wonder if there is a problem with nearly-full BtrFS or with BtrFS that were once converted from ext3? Hi Not sure if previous filesystems would be an issue, I always clear out with wipefs on a drive on fresh installs.
I would setup a weekly cronjob with a softlink to that script, also is the snapper cronjob running daily to reduce snapshots? -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.39-47-default up 1 day 0:17, 4 users, load average: 0.28, 0.45, 0.41 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 Wed, 29 Apr 2015 12:30:34 Anton Aylward wrote:
On 04/29/2015 11:41 AM, Malcolm wrote:
There is a balance script you can run; /usr/share/btrfsmaintenance/btrfs-balance.sh
That reduced my use from 65% to 60%.
I wonder if there is a problem with nearly-full BtrFS or with BtrFS that were once converted from ext3?
Um ,yeah, there's a problem - it's called BTRFS. ;) My home network is officially a btrfs-free zone... -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/30/2015 09:43 AM, Rodney Baker wrote:
Um ,yeah, there's a problem - it's called BTRFS.
;)
I'm reminded at this point about electoral politics. Example: the party whose representative didn't make it to the presidency bitches about that fact. The reality is that bitching isn't going to change that. It isn't going to change the adoption of BtrFS. Just like you hope the prez will do good stuff, we hope that BtrFS will get cleaned up and work properly. In the mean time you have alternatives. Strangely enough the supposedly orphaned ReiserFS got a state of high reliability PDQ. Using ReiserFS on LVM offers many of the supposed advantages of BtrFS, without the hassle of snapshots running amok but without the SSD tweaks. I'm sticking with ReiserFS for production for the moment. I'll keep a play machine for BtrFS. Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS. -- 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
Am 30.04.2015 um 16:50 schrieb Anton Aylward:
On 04/30/2015 09:43 AM, Rodney Baker wrote:
Um ,yeah, there's a problem - it's called BTRFS.
;)
I'm reminded at this point about electoral politics. Example: the party whose representative didn't make it to the presidency bitches about that fact. The reality is that bitching isn't going to change that.
It isn't going to change the adoption of BtrFS.
Just like you hope the prez will do good stuff, we hope that BtrFS will get cleaned up and work properly.
In the mean time you have alternatives. Strangely enough the supposedly orphaned ReiserFS got a state of high reliability PDQ. Using ReiserFS on LVM offers many of the supposed advantages of BtrFS, without the hassle of snapshots running amok but without the SSD tweaks.
I'm sticking with ReiserFS for production for the moment. I'll keep a play machine for BtrFS.
Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS.
To me btrfs goes to the same chapter as kmail. Once a good idea, but in the end unusable and one has to switch to alternatives. In all the years on this list I never read so much about problems with an fs like with btrfs. Unless it changes /completely/ I'd never take it into consideration. I am concerned about the fact that Reiserfs isn't in the install options of OS anymore. It is in fact the best file system (IMHO) and I don't know what one can do that it returns into OS's options when installing. At least it can still be used when formated with a third party program. -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/30/2015 11:02 AM, Daniel Bauer wrote:
To me btrfs goes to the same chapter as kmail. Once a good idea, but in the end unusable and one has to switch to alternatives.
Sadly, yes. part of what is a downer with Kmail is the Borg-like attitude of PIM-integration with ... What is it now? Baloo? Akonadi? That in turn drags in so much more. Perhaps if Kmail and Konq-as-web-browser had anything like the capabilities of Thunderbird and Firefox I'd be more sympathetic. I might put up with other issues; heck, T'Bird and FF have their own problems! But right now their capabilities are so far ahead of Kmail and Konqueror, and of QupZilla too for that matter!, it make me wonder what the KDE people are thinking. Email and Web browsing are so fundamental to computer use. The office suite may be cool and business like, but email and web browsing is universal. In all the years
on this list I never read so much about problems with an fs like with btrfs. Unless it changes /completely/ I'd never take it into consideration.
As I said, we may not have a choice. Any more than we had with KDE in the 3->4 Transition. Well OK, pressure there kept a version of "3" around and people stepped up to the plate to maintain it. The issue here is this: will disgust with BtrFS cause people to step up to the plate to maintain ReiserFS?
I am concerned about the fact that Reiserfs isn't in the install options of OS anymore. It is in fact the best file system (IMHO) and I don't know what one can do that it returns into OS's options when installing. At least it can still be used when formated with a third party program.
That ResierFS is surviving is a testimony to its excellent design and craftsmanship. If the same went into BtrFS, if Hans could have worked on it from his jail cell, perhaps ... Who knows. -- 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 Thu, 30 Apr 2015 10:50:32 Anton Aylward wrote:
On 04/30/2015 09:43 AM, Rodney Baker wrote:
Um ,yeah, there's a problem - it's called BTRFS.
;)
I'm reminded at this point about electoral politics. Example: the party whose representative didn't make it to the presidency bitches about that fact. The reality is that bitching isn't going to change that.
It isn't going to change the adoption of BtrFS.
Agreed. I'm not bitching about it, but I can choose not to use it too. The first and only time I allowed it to install, after a few weeks I ended up with an unbootable, unfixable system. Why? Because / was full , and corrupted, and would only mount ro. The filesystem maintenance tools (if they'd been available and installed) live on /, and / has to be mounted to access them, except you can't repair a mounted filesystem, so you have to unmount it, which means you now have no filesystem checking tools...and of course the system will only boot into emergency maintenance mode, and I can't install the tools needed to fix it because zypper won't run because /var is mounted ro... This was about the time when I reinstalled the system from scratch using ext4...
Just like you hope the prez will do good stuff, we hope that BtrFS will get cleaned up and work properly.
Yes, and it would be nice if the distro packagers would set some sensible defaults at install time, by which I mean settings that make sure your / filesystem isn't going to be unusable in 3 months' time. At least you do have the option of disabling snapshots at install time, but how many people understand what that means and its effects (positive or negative)? Some explanation in the install process would be helpful,(but I guess the standard answer to that would be RTFM...except that these days that would need to be modified to DARTFM (Download and read...). :)
In the mean time you have alternatives.
Vive la choices! :)
Strangely enough the supposedly orphaned ReiserFS got a state of high reliability PDQ. Using ReiserFS on LVM offers many of the supposed advantages of BtrFS, without the hassle of snapshots running amok but without the SSD tweaks.
Interestingly, the Samsumg proprietary ssd management tools only support trim on ext4 (or NTFS on 'Doze).
I'm sticking with ReiserFS for production for the moment. I'll keep a play machine for BtrFS.
Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS.
Never experienced inode exhaustion, and rotating rust is cheap these days. :) However, none of this venting is likely to be helpful to the OP, so I'll shut up now and go to bed. :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/30/2015 12:09 PM, Rodney Baker wrote:
On Thu, 30 Apr 2015 10:50:32 Anton Aylward wrote:
On 04/30/2015 09:43 AM, Rodney Baker wrote:
Um ,yeah, there's a problem - it's called BTRFS.
;)
I'm reminded at this point about electoral politics. Example: the party whose representative didn't make it to the presidency bitches about that fact. The reality is that bitching isn't going to change that.
It isn't going to change the adoption of BtrFS.
Agreed. I'm not bitching about it, but I can choose not to use it too.
I think that's wonderful! Windows, what I've seen of OSX, even Android, doesn't seem to offer such choices as we have with Linux.
The first and only time I allowed it to install, after a few weeks I ended up with an unbootable, unfixable system. Why? Because / was full , and corrupted, and would only mount ro. The filesystem maintenance tools (if they'd been available and installed) live on /, and / has to be mounted to access them, except you can't repair a mounted filesystem, so you have to unmount it, which means you now have no filesystem checking tools...and of course the system will only boot into emergency maintenance mode, and I can't install the tools needed to fix it because zypper won't run because /var is mounted ro...
Two things. The first is obviously that BtrFS is still in development and is a moving target, and "that was then, this is now". The second is in the class of "its your own XXXXXX fault" for whatever value of XXXXXX least annoys you. When I first did this experiment I made rootfs ReiserFS as I always do and used BtrFS on /home. Scratch machine. I lost /home! But it was still bootable. I've got nothing against resuming mounted file systems can't be repaired once foooooooked. I've got nothing against booting from the repair DVD and doing whatever fsck and other stuff like chroot and mkinit. BTDT got good at it :-( But I never did get taken in by this idea that the root BtrFS should take in the rest of the file hierarchy. I've always made /home, /tmp, /var and if not /usr then at least /usr/share separate partitions. call me paranoid. Call me obsessive. I don't care. It means I have more resilient systems. I love LVM. Having /var as part of the RootFS BtrFS is crazy! It means your hourly snapshots will be HUGE!
This was about the time when I reinstalled the system from scratch using ext4...
Just like you hope the prez will do good stuff, we hope that BtrFS will get cleaned up and work properly.
Yes, and it would be nice if the distro packagers would set some sensible defaults at install time, by which I mean settings that make sure your / filesystem isn't going to be unusable in 3 months' time. At least you do have the option of disabling snapshots at install time, but how many people understand what that means and its effects (positive or negative)? Some explanation in the install process would be helpful,(but I guess the standard answer to that would be RTFM...except that these days that would need to be modified to DARTFM (Download and read...). :)
There you have it. I've never understood this thing about doing an install taking defaults. Much as I respect Chris Murphy on BtrFS and other points, his rant over (around 8th march onwards) the installation took no account of the fact that the installation is from a 'script' and can include or omit anything you want, have any defaults you want. I've done this with autoyast, reduced it to a 'trojan' that installs Linux (originally as a docker) with zero interaction and the defaults that *I* decided on. Hmm. That would make a nice trojan to carry into bestbuy .....
In the mean time you have alternatives.
Vive la choices! :)
Strangely enough the supposedly orphaned ReiserFS got a state of high reliability PDQ. Using ReiserFS on LVM offers many of the supposed advantages of BtrFS, without the hassle of snapshots running amok but without the SSD tweaks.
Interestingly, the Samsumg proprietary ssd management tools only support trim on ext4 (or NTFS on 'Doze).
I'm sticking with ReiserFS for production for the moment. I'll keep a play machine for BtrFS.
Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS.
Never experienced inode exhaustion, and rotating rust is cheap these days. :)
It may be so, but backup onto USB stick is not rotating rust. My point is that ReiserFS does so much more and avoids many issues of that stupid archaism about the trade-off between inode space and data space that we've had since version 6 UNIX in the 1970s. I hated it then and I hate it now. Saying Bid Disks and over-provisioning misses the point. Backup management, unless you have a few 2T tape mechanism, is a limit. I back up to DVD or to mid size USB, though the new 128GB MicroSDXC are getting reasonable for rsync/incremental. -- My definition of an expert in any field is a person who knows enough about what's really going on to be scared. P. J. Plauger, Computer Language, March 1983 -- 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-30 19:22, Anton Aylward wrote:
Having /var as part of the RootFS BtrFS is crazy! It means your hourly snapshots will be HUGE!
I think that you can adjust the periodicity (and the purging) separately for /var. Adjusting it correctly and it shouldn't be a problem.
Hmm. That would make a nice trojan to carry into bestbuy .....
:-)
Never experienced inode exhaustion, and rotating rust is cheap these days. :)
You can get it easily enough on mail/nntp partitions. They should be partitions in order to increase the inode ratio... (see man mkfs.ext2, - -T option).
My point is that ReiserFS does so much more and avoids many issues of that stupid archaism about the trade-off between inode space and data space that we've had since version 6 UNIX in the 1970s. I hated it then and I hate it now.
True. XFS does it, too. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVCdAgACgkQja8UbcUWM1xsNwD/fviBJHVHX2GVHkm0F8UVozJy eojvYGWUSxkdAj6uHtgA/2yDkX2iWjUH52T6hyTp1dUHmLh0zudWB4iFy0yiQq6c =dj9k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/30/2015 02:27 PM, Carlos E. R. wrote:
On 2015-04-30 19:22, Anton Aylward wrote:
Having /var as part of the RootFS BtrFS is crazy! It means your hourly snapshots will be HUGE!
I think that you can adjust the periodicity (and the purging) separately for /var. Adjusting it correctly and it shouldn't be a problem.
Looking at the config ... if /var is part of rootFS, a subvolume or not, .... as opposed to being a separately implemented file system as in /dev/mapper/vgmain-vVar on /var type btrfs (rw,relatime,space_cache) I wonder how. Do you have to have a separate config file for each subvolme or mounted FS you want to snapshot? I've tried creating /etc/snapper/configs/var but the yas2 module error-exits. -- 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-05-01 00:33, Anton Aylward wrote:
On 04/30/2015 02:27 PM, Carlos E. R. wrote:
On 2015-04-30 19:22, Anton Aylward wrote:
Having /var as part of the RootFS BtrFS is crazy! It means your hourly snapshots will be HUGE!
I think that you can adjust the periodicity (and the purging) separately for /var. Adjusting it correctly and it shouldn't be a problem.
Looking at the config ...
Hey, I don't know how to do it :-) I just read someone mentioned that it was an advantage of using separate volumes in the same partition. Or the reason for doing it, that you could do separate adjustments on each space. But don't ask me how, I don't use btrfs. Maybe some day in the (not near) future... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVCtdkACgkQja8UbcUWM1xLQQD/Vv+xhPxk2oMw+TMiN3ZwVqcY eW51mzbJb4ozh4EaNv4A/1QvTHNHMQemnjklLcPBBVm3PsOQ+iOD7MyUolDuOcLX =2fmt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 30 April 2015 10:50:32 Anton Aylward wrote:
Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS.
Could you please explain it in more details? That sounds quite scary, just when I thought to reformat my /home from btrfs to ext4 (leave btrfs for /) your story may affect my final decision to do it... -- Regards, Stas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/30/2015 01:49 PM, Stanislav Baiduzhyi wrote:
On Thursday 30 April 2015 10:50:32 Anton Aylward wrote:
Ext4? Sorry, I'm not going to get bitten by inode exhaustion again, and i think having to massively over-provision is a ridiculous strategy. Better to have the integrated b-tree as well as the 'stuffing' of ReiserFS.
Could you please explain it in more details? That sounds quite scary, just when I thought to reformat my /home from btrfs to ext4 (leave btrfs for /) your story may affect my final decision to do it...
Explain what? ReiserFS tail end stuffing? Its documented out there on the web better than I could explain it. Loosing my /home? Well that was a year or more ago, and I've even replaced my hard drive since then :-) There have been many updates to BtrFS since then. I ran the 3.19 series kernels until this last week when I switched to the 4.0 series. Under the 3.19 I never had losses. The losses were with the 3.11 stock kernel that came on the 13.1 DVD. If you're nervous, try BtrFS on something non-critical, easily replaced, like /tmp or /usr/share. I'd suggest /var but you'd better make sure there are no snapshots taken! on my scratch machine I have /usr as btrfs. Opportunity for lots of subvolumes! -- 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 04/29/2015 11:05 AM, Malcolm wrote:
Have you adjusted the snapper config?
IMHO that is key and could relate to Patrick's problem too. Default is to create snapshots hourly ... And delete some hourly. If that turns out wrong, somehow, it can produce the fillup/empty cycle. Yes, I know snapshots are supposed to be about things that change and are supposed to be COW, but things can go wrong. I see watching the appropriate list that a lot of patches occur DAILY and many of them imply the FS isn't doing what the design specs say it was supposed to. This might be one area with the revision Patrick has. Possibly .... Maybe ... Somehow. Worth checking? -- 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 04/29/2015 09:08 AM, Anton Aylward wrote:
On 04/29/2015 11:05 AM, Malcolm wrote:
Have you adjusted the snapper config?
IMHO that is key and could relate to Patrick's problem too.
Default is to create snapshots hourly ... And delete some hourly. If that turns out wrong, somehow, it can produce the fillup/empty cycle.
Yes, I know snapshots are supposed to be about things that change and are supposed to be COW, but things can go wrong. I see watching the appropriate list that a lot of patches occur DAILY and many of them imply the FS isn't doing what the design specs say it was supposed to. This might be one area with the revision Patrick has.
Possibly .... Maybe ... Somehow. Worth checking?
Part of the problem with hourly is that it just snapshots far too much of the system, picking up things that are inflight, mail queues, and such. Btrfs mostly behaved when I suppressed hourly, reduced the number of snapshots retained on all the others. But then I had filesystem corruption twice in 6 months and the second time I lost data. That was the end of my btrfs experiment. When the patch frequency falls to monthly I may revisit it, although I can't say as I saw any real benefit. Subtly pushing btrfs as the suggested file system was a courageous step on Opensuse's part. Sort of like when they "suggested" KDE4 two years before it was useable. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/29/2015 02:04 PM, John Andersen wrote:
Subtly pushing btrfs as the suggested file system was a courageous step on Opensuse's part. Sort of like when they "suggested" KDE4 two years before it was useable.
Well, yes, there is that :-( -- The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts. --Bertrand Russell -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/29/2015 09:06 AM, jdd wrote:
Hello,
I was hit this morning by the "no space left on the device" symptom, probably related to BTRFS (?), when btrfs's df (znd normal df) gives at least half space free.
To work I had to reinstall on the other disk a 13.2 version (with ext4, this time).
I know it's a discussed problem, and I read many posts on the subject, but It still don't get how to solve it.
I *can* login with the failsafe mode, as root (or not), CLI only, but any action that include temp file fails with "no space left on the device", yast segfault...
I cleared /tmp and some files in /home with no change.
Is it possible to recover this? how?
thanks jdd
All of this needs reporting to both suse bugzilla and upstream. There is a horrible problem with btrfs and general defaults and usability for the normal user. It is about as ready for primetime as KDE 4.0.4 was with openSuSE 11.0 in June 2008. There is never an excuse for a new, relatively experimental, FS to be offered/proposed for user install by a distro when issues of data loss are a regular occurrence -- period. It needs reporting to opensuse so the install choices ordering and warning can be appropriately included in the installer; and It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it, can have it so these issues with snapshotting and space exhaustion can be fixed before this FS politics/dupes itself into a default install on some distro somewhere. I wouldn't touch this thing with a 10 foot pole at the moment. -- 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 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it
I do note a couple of things that need to be taken into account before doing the Chicken Little dance. 1. Jdd did not say what version of BtrFS & utilities, or kernel this is. There are two issues there. The first is that such information is needed for a bug report The Second is to see if this has bee reported already for that version. 2. I watch the btrfs-users list and there are, on average, 5 patches or revisions a day. These seem to be fixes. I see the occasions request for an upgrade, but that is not an area where things are being aggressively persuaded. The reason I mention this is that your argument, David, is weakened by the fact that not only are developers taking note of problems but they are actively working on this. It is unfair to condemn n BtrFS when this much commitment is being made towards its success. I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. -- 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 03/05/2015 15:27, Anton Aylward a écrit :
On 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it I do note a couple of things that need to be taken into account before doing the Chicken Little dance.
1. Jdd did not say what version of BtrFS & utilities, or kernel this is.
this hit me just when I was packing for osc-15, so no time to give more info, I needed the computer to run FAST! :-( sorry :-( I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. I completely agree with you? That said so harsh things should not happen on regular release :-( thanks jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 09:45 AM, jdd wrote:
I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided.
There is one BIG difference though. When I get an update to KDE4 or one of its components like kate, Calligra or gwenview I just log out of the application or possibly out of KDE. More often than not the updates are to libraries and that may impact a number of applications. But with the patches to BtrFS its different. Its not like its a FUSE application. It kernel, its core. And since many of us are running BtrFS on the rootFS its not something that can easily be patched on the fly even if using the 4.x kernel. Its a reboot. And that's assuming that the kernel gets rebuilt daily. Sorry, I'm not into doing a git fetch and building my own kernel! yes its important to report bugs to the developers, but the nature of this cycle means that for most of us the developers are long, long past the revision of BtrFS in the kernel in use. And how exactly does the ordinary openSuse user determine what version of BtrFS is in the version of the kernel he's using? See also https://btrfs.wiki.kernel.org/index.php/FAQ#Are_btrfs_changes_backported_to_... I have Information for package btrfsprogs: ----------------------------------- Repository: openSUSE BuildService - filesystems Name: btrfsprogs Version: 4.0-184.1 Arch: x86_64 Vendor: obs://build.opensuse.org/filesystems Installed: Yes Status: up-to-date Installed Size: 3.0 MiB Summary: Utilities for the Btrfs filesystem Description: Utilities needed to create and maintain btrfs file systems under Linux. Information for package btrfsmaintenance: ----------------------------------------- Repository: openSUSE BuildService - filesystems Name: btrfsmaintenance Version: 0.1-10.1 Arch: noarch Vendor: obs://build.opensuse.org/filesystems Installed: Yes Status: up-to-date Installed Size: 29.6 KiB Summary: Scripts for btrfs periodic maintenance tasks Description: Scripts for btrfs maintenance tasks like periodic scrub, balance, trim or defrag on selected mountpoints or directories. Both those are up to date but the numbering doesn't correspond to the version of kernel I have 4.0.0-4.g27299c0-desktop #1 SMP PREEMPT Fri Apr 24 12:39:28 UTC 2015 -- 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 05/03/2015 08:45 AM, jdd wrote:
Le 03/05/2015 15:27, Anton Aylward a écrit :
On 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it I do note a couple of things that need to be taken into account before doing the Chicken Little dance.
1. Jdd did not say what version of BtrFS & utilities, or kernel this is.
this hit me just when I was packing for osc-15, so no time to give more info, I needed the computer to run FAST! :-( sorry :-( I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. I completely agree with you? That said so harsh things should not happen on regular release :-(
thanks jdd
Anton, JDD, This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP: <quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote> WTF? You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..?? Forgive me for expecting more from filesystem developers and distributions. When Linux is touted as an alternative for new users to try, then we have got to quit doing things like this. Anton, JDD, myself and others here, can look at whats going on with a FS and can be expected to help by reporting bugs, etc.. That's not what this cautionary tale is about. This is about the user that gets a copy of the openSuSE install and says, you know, I've heard good things about Linux, I think I'll pop this install in.... btrfs, xfs, reiserfs, ext3, ext4, etc.. mean nothing to the user and if he says, "hmm.., this btrfs is at the front of the list, it must be the most reliable, I'll try it"... Watch out.. I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs. My recommendation to both file here and upstream is exactly what need to be done to move development along, and if the folks on Factory are aware of these failures, then the installer should be adjusted or a warning added that btrfs is under development and should not be used for production installs. That's not chicken little, that just smart. It will get there I'm sure, but until it does, and at least until the issues with snapshot space exhaustion are fixed and *validated*, it should only be offered as an experimental FS. -- 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 05/03/2015 01:46 PM, David C. Rankin wrote:
Anton, JDD,
This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP:
That is complete and utter nonsense. Plenty of people at RedHat and Novell can tell you otherwise.
<quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote>
WTF?
You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..??
Stop exaggerating, David. This was never 'unexpected', it was highly publicised. As I've said repeatedly, Linux is about CHOICES and you can choose what FS to use where. Its Windows where you don't have the choices. Yes having to make decisions is stressful. Having to decide how to partition things is stressful. Mind you, I have a partition for my photographs, by year, and also by special outings. I have a partition for "financials", that is accounts, tax records, communications with banks, bank statements, bills. These get backed up They get backed up separately. I *CHOOSE* to do that. Linux is about choices. Even if you take the defaults, there is a separate /home for all your treasures. IIR the default for that is now XFS. Also IIR XFS has been around longer, is more proven that ext4. Personally I think 7 have found ReiserFS to be the most reliable so I *CHOOSE* to make use of that on my productions partitions where I keep the above mentioned
Forgive me for expecting more from filesystem developers and distributions. When Linux is touted as an alternative for new users to try, then we have got to quit doing things like this. Anton, JDD, myself and others here, can look at whats going on with a FS and can be expected to help by reporting bugs, etc.. That's not what this cautionary tale is about.
This is about the user that gets a copy of the openSuSE install and says, you know, I've heard good things about Linux, I think I'll pop this install in....
And is presented with choices. perhaps he's been brainwashed by the Establishment into thinking that he never needs to make choices, but life's not like that. The reality is that if he's got this far he's curious and is a 'tinkerer'. Heck, even Windows accommodates tinkerers to a high degree, they can fiddle with their machines 'appearance' in so many ways and do meaningless things like de-fragment their disk and install AV. The Linux installer gives them lots and lots of 'buttons' and things to play with.
btrfs, xfs, reiserfs, ext3, ext4, etc.. mean nothing to the user and if he says, "hmm.., this btrfs is at the front of the list, it must be the most reliable, I'll try it"... Watch out..
First on a n alphabetic list ... Your exaggerating again, David. You're treating whoever it is that is curious enough to experiment with wiping out Windows to install Linux as of he was dumb. And yes, perhaps he's not going to wipe his disk and devote it to Linux, perhaps he's taken the time read up on shrinking the Windows partition, which means he's gained a modicum of knowledge about partitioning. Perhaps he's not the idiot you make him out to be and actually read a couple or more articles and this has led him to mention of file systems. The history of BtrFS is, I don't disagree, ignominious. Perhaps he's found this because he's googles -- and who isn't smart enough to "Go Google" in this day and age before undertaking a new venture so as to better understand alternatives and risks ... Its the "Foder's Guide to ..." just about everything. Or perhaps he joins a 'new-to-Linux' list somewhere or even *shock horror* one like this! But assuming that because he has CHOSEN to install Linux that is it and he's incapable of making further *CHOICES* or asking the 'what if ..' or 'can I...' questions presupposes he' in the lower rankings of any intelligence scale and that is just plain INSULTING.
I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs.
LOL! Well UNIX began with one of the most unreliable file systems imaginable, the fames V6/V6 file system. Even though the Berkeley Fast File System was 'better organized' it still was not log oriented. It was a long time before people realized that you had to write the data and the metadata separately AND IN THE RIGHT ORDER to be able to have it in a way that could survive a crash, and even longer before we go log oriented file systems. Later studies and models showed that a log oriented file system was adequate and could be extended so that if the logging was goo enough you didn't need the file system :-) So your assertion of 17 years is sort of iffy, David. You do take regular backups, I take it? One of the things about BtrFS (and XFS) is that snapshots are a form of backup. When I've used "Real Computers" and you get a patch, you can back out of a applying that patch. By that definition UNIX never was and Linux hasn't been a "Real Computer". But now with snapshots built in the zypper-type operations (be they command line, Yast or automatic) we have that capability. Snapshots can also facilitate daily backups. Yes I realise that puts a load on the amount of space, but as many have pointed out, 'rotating rust is cheap'. I wonder if many of the problems that have arise with BtrFS is because they are on too small a partition? -- 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 05/03/2015 02:50 PM, Anton Aylward wrote:
Mind you, I have a partition for my photographs, by year, and also by special outings. I have a partition for "financials", that is accounts, tax records, communications with banks, bank statements, bills.
These get backed up They get backed up separately.
This was my whole point..... The new user who says, "gee, I think I'll pop this disk in and install it.." is the person to keep in mind. I'm not worried about the experienced user who has good backup practices, etc.., etc.., etc... Unless we now want to change the narrative from "Linux is a safe, solid and secure alternative, give it a try" to "Don't try it unless everything is backed up separately", then it just makes sense to provide filesystem recommendations accordingly. Sheesh, it doesn't take rocket-science to figure out, "hmm.., if this FS is not yet fully baked, then maybe suggesting one that is is the proper course", but apparently it does. That's all I'm saying. When we talk about not using btrfs in out "production machines" yet, then if we are not passing that information along to new users via FS selection ordering or at least providing a prominent note reflecting its status, then we are doing a disservice. I'm not going to go pull quotes from all the threads on this issue, but it is a fair summary that for 90% of those who have experienced FS space exhaustion with btrfs -- would not have selected btrfs and would not have ended up in that situation if they had been given information regarding btrfs's potential to do that. In other words, if they had been given enough information to make an educated decision about whether they wanted to try an experimental FS with the potential for data loss, or stick with a tried and true FS, 90% of those hit with data loss would not have chosen btrfs to begin with. So do we give users sufficient information to make an educated choice at filesystem selection time, or do we just continue to use the suckers that choose btrfs as unwitting guineas? Even if we didn't know about the potential for FS exhaustion due to the snapshotting when 13.1 was released, we damn sure know about it now, and should act accordingly. Or we can fail to learn from history once again and be destined to repeat them over and over again... I fall into the camp that says "if you know about a problem, you have a duty to warn about it and to take steps to insure the problem can be made reasonably safe." To me that means an clear and prominent installer note at FS selection time so users can choose whether to become beta testers or not. I don't think that is asking too much and I don't think that is "chicken little", I just think that's smart. Note: ad hominem replies are deleted without further reading. -- 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
Le 05/05/2015 19:26, David C. Rankin a écrit :
Unless we now want to change the narrative from "Linux is a safe, solid and secure alternative, give it a try" to "Don't try it unless everything is backed up separately", then it just makes sense to provide filesystem recommendations accordingly.
I don't think I have a system similar at the one a new user have. few people have 10Gb openSUSE root system with tons of updates. I just happen to try many things. till now I don't have had any problem with my much less loaded laptop ! ... but it may come. This laptop have a curious result when I test it, more later if I can sort this out (no time right now, sorry) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 01:46 PM, David C. Rankin wrote:
Anton, JDD,
This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP:
<quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote>
WTF?
You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..??
oh bullshit. I had a friend who last year lost every single picture of her children, age 7 and 5, because they were on here "enterprise" windows desktop, the current version as a matter of fact, which was venerable to a ransom virus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 01:28 PM, Ruben wrote:
oh bullshit. I had a friend who last year lost every single picture of her children, age 7 and 5, because they were on here "enterprise" windows desktop, the current version as a matter of fact, which was venerable to a ransom virus
And that's HIS problem, not Window's problem. And certainly not a FileSystem problem. Saying that everything is OK just because there is something worse on the other side of the fence is sort of a red herring. Lets keep this thread focused on the problem at hand. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 10:46 AM, David C. Rankin wrote:
I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs.
While some parts of your post may have been over the top, (just a tad), by and large this is spot on. Look to my left, I see a very heavily uses Windows 7 (upgraded from Vista) 7 or 9 years old, and I've never had a bit of file system problems in-spite of it running almost 24/7 over those years. I have an old Opensuse file server, much older running Reiserfs on mdRaid, probably 12 years old and had problems exactly once when a disk failed. _No data loss._ No need to restore from backup. Yet my main Linux machine had two BTRFS crashed, necessitating FS rebuilds, one with massive data loss, requiring re-installation. (yes it was backed up). _All within 6 months_. (I didn't have my work source code library nor my /home directory on BTRFS, thank my lucky stars.) Additionally, opensuse decided to never purge ANY temp files, and save ridiculous amounts BTRFS snapsots, and put /tmp and /var/tmp on BTRFS as sub-volumes putting the whole installation at risk of a full /tmp, on an experimental file system. /Root would have been fine on btrfs, because you should be able to install anything on there again if it goes bad (other than /etc). But /tmp and /var/tmp are very active and dynamic. Side Issue --------- (or maybe the root problem?) As best I understand the situation, MicroFocus (yes the PC COBOL company) now owns Suse Linux. Therefore Opensuse is no longer a testbed for SLED/SLES. Its time for Opensuse to stop serving as the crash-test-dummy distro. -- After all is said and done, more is said than done. -- 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-05-03 23:45, John Andersen wrote:
Its time for Opensuse to stop serving as the crash-test-dummy distro.
Well, once upon a time, SuSE decided that the default filesystem would be reiserfs, which was not even included in the upstream kernel sources, it had not yet been accepted. It was considered experimental. But they did. And there were bugs, and some people lost data. Yes, I remember one such, had to reformat my filesystem. But here we are now... where we /still/ consider reiserfs to be one of the best filesystems in existence - because SuSE took the plunge and made us use it. (In fact, I have seen filesystem crashes with probably every filesystem types.) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVGs14ACgkQja8UbcUWM1yt9wD+Lr8d3G4Sa/XFdfX0PD3gt3y/ oqDFjC2ALRy0ttAVuwkA/3VFNFgOuKnfnQM6btA86epqCQbi9mtxuPIS54pKnray =Swt5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 05:45 PM, John Andersen wrote:
Additionally, opensuse decided to never purge ANY temp files, and save ridiculous amounts BTRFS snapsots, and put /tmp and /var/tmp on BTRFS as sub-volumes putting the whole installation at risk of a full /tmp, on an experimental file system.
No argument there! But then again, even before BtrFS there was the whole issue of whether /tmp though be a real file system or a tmpFS aka memory mapped. There have been security flaws over the years that make it advisable to have a /tmp or at least a download area that is mounted non executable. I'm aware of read-only snapshots (useful for backups) but I'm not clear on whether a subvolume can be mounted non-executable[1]. I'm really not happy with the idea that the BtrFS will/should/might take over the whole file tree. But that's another matter. We can also argue over such thins as :should /usr/tmp be symlinked to /tmp?" /usr/tmp -> /var/tmp Of course /var should be writable :-) /usr need not. Hence that symlink. [1] As SUN showed with its networked worked stations back in the 1980s and onwards, where you could log in 'anywhere', its not a good idea to have much of the file tree writeable, never mind executable. Much of the file tree is owned and only writeable by root and the shared environment things like /usr/share really really are shared. There is no reason /etc shouldn't be as well. Limiting where executables can reside and their permission eliminates many of the security problems inherent with Windwos. Of course a user can always 'run as root' whcih gets back to the problem we always had with Windows, but in a shared/service setting that's less likely. -- 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-05-04 03:32, Anton Aylward wrote:
I'm aware of read-only snapshots (useful for backups) but I'm not clear on whether a subvolume can be mounted non-executable[1].
Well, if the subvolumes have entries in fstab, certainly you can use different entries for each one. I can not test this myself, though, I don't use 13.2 - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVHhBYACgkQja8UbcUWM1zWawD9GjKGYVjIETxDGJyrgch/kAOo WvANDzt6wi+lviR/NXUA/1dkwacxTtAnMEliMG1Kj1/Tc6m8HgXpIqidXrq2YGyL =hYQp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/03/2015 01:46 PM, David C. Rankin wrote:
On 05/03/2015 08:45 AM, jdd wrote:
Le 03/05/2015 15:27, Anton Aylward a écrit :
On 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it I do note a couple of things that need to be taken into account before doing the Chicken Little dance.
1. Jdd did not say what version of BtrFS & utilities, or kernel this is.
this hit me just when I was packing for osc-15, so no time to give more info, I needed the computer to run FAST! :-( sorry :-( I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. I completely agree with you? That said so harsh things should not happen on regular release :-(
thanks jdd
Anton, JDD,
This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP:
<quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote>
WTF?
You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..??
Forgive me for expecting more from filesystem developers and distributions. When Linux is touted as an alternative for new users to try, then we have got to quit doing things like this. Anton, JDD, myself and others here, can look at whats going on with a FS and can be expected to help by reporting bugs, etc.. That's not what this cautionary tale is about.
This is about the user that gets a copy of the openSuSE install and says, you know, I've heard good things about Linux, I think I'll pop this install in....
btrfs, xfs, reiserfs, ext3, ext4, etc.. mean nothing to the user and if he says, "hmm.., this btrfs is at the front of the list, it must be the most reliable, I'll try it"... Watch out..
I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs. My recommendation to both file here and upstream is exactly what need to be done to move development along, and if the folks on Factory are aware of these failures, then the installer should be adjusted or a warning added that btrfs is under development and should not be used for production installs. That's not chicken little, that just smart.
It will get there I'm sure, but until it does, and at least until the issues with snapshot space exhaustion are fixed and *validated*, it should only be offered as an experimental FS.
Like David, I have over 20 years experience using linux and have become appalled at the development model of the last few years. SuSE stood for quality when I first stated using it (1998) and now (to me) it has become a test bed with the mentality that if you don't like what we force upon you go somewhere else for your linux needs. When my choice of how to build MY linux system is taken away I will then move to another distro. And I refuse to use BTRFS until I stop hearing/reading reports of users disk filling up and or crashing with recovery possible. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 11:13 AM, Ken Schneider - openSUSE wrote:
On 05/03/2015 01:46 PM, David C. Rankin wrote:
On 05/03/2015 08:45 AM, jdd wrote:
Le 03/05/2015 15:27, Anton Aylward a écrit :
On 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it I do note a couple of things that need to be taken into account before doing the Chicken Little dance.
1. Jdd did not say what version of BtrFS & utilities, or kernel this is.
this hit me just when I was packing for osc-15, so no time to give more info, I needed the computer to run FAST! :-( sorry :-( I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. I completely agree with you? That said so harsh things should not happen on regular release :-(
thanks jdd
Anton, JDD,
This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP:
<quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote>
WTF?
You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..??
Forgive me for expecting more from filesystem developers and distributions. When Linux is touted as an alternative for new users to try, then we have got to quit doing things like this. Anton, JDD, myself and others here, can look at whats going on with a FS and can be expected to help by reporting bugs, etc.. That's not what this cautionary tale is about.
This is about the user that gets a copy of the openSuSE install and says, you know, I've heard good things about Linux, I think I'll pop this install in....
btrfs, xfs, reiserfs, ext3, ext4, etc.. mean nothing to the user and if he says, "hmm.., this btrfs is at the front of the list, it must be the most reliable, I'll try it"... Watch out..
I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs. My recommendation to both file here and upstream is exactly what need to be done to move development along, and if the folks on Factory are aware of these failures, then the installer should be adjusted or a warning added that btrfs is under development and should not be used for production installs. That's not chicken little, that just smart.
It will get there I'm sure, but until it does, and at least until the issues with snapshot space exhaustion are fixed and *validated*, it should only be offered as an experimental FS.
Like David, I have over 20 years experience using linux and have become appalled at the development model of the last few years. SuSE stood for quality when I first stated using it (1998) and now (to me) it has become a test bed with the mentality that if you don't like what we force upon you go somewhere else for your linux needs. When my choice of how to build MY linux system is taken away I will then move to another distro. And I refuse to use BTRFS until I stop hearing/reading reports of users disk filling up and or crashing with recovery possible.
Meant to say "with NO recovery possible". -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 08:19 AM, Ken Schneider - openSUSE wrote:
On 05/04/2015 11:13 AM, Ken Schneider - openSUSE wrote:
On 05/03/2015 01:46 PM, David C. Rankin wrote:
On 05/03/2015 08:45 AM, jdd wrote:
Le 03/05/2015 15:27, Anton Aylward a écrit :
On 05/01/2015 09:09 PM, David C. Rankin wrote:
It needs reporting upstream so real-world data is available to the developers, who obviously don't live in it I do note a couple of things that need to be taken into account before doing the Chicken Little dance.
1. Jdd did not say what version of BtrFS & utilities, or kernel this is.
this hit me just when I was packing for osc-15, so no time to give more info, I needed the computer to run FAST! :-( sorry :-( I sympathise with the idea that BtrFS, like KDE4, has been forced on users, but the reality is that unless this kind of push is made how else are users going to aggressively debug this in the field, as you quite rightly point out. There is a limit to what developers can do unaided. It is unfortunate that this technique also garners a bad reputation for the later, stable, functional releases. I completely agree with you? That said so harsh things should not happen on regular release :-(
thanks jdd
Anton, JDD,
This entire premise is WRONG, and it IS THE REASON LINUX HAS NEVER BEEN A LEGITIMATE BUSINESS DESKTOP:
<quote>
but the reality is that unless this kind of push is made how else are *users* going to aggressively debug this in the field...
</quote>
WTF?
You foist an experimental filesystem on unsuspecting *users* wanting them to *aggressively debug* with what might be their family photos, financial data, etc..??
Forgive me for expecting more from filesystem developers and distributions. When Linux is touted as an alternative for new users to try, then we have got to quit doing things like this. Anton, JDD, myself and others here, can look at whats going on with a FS and can be expected to help by reporting bugs, etc.. That's not what this cautionary tale is about.
This is about the user that gets a copy of the openSuSE install and says, you know, I've heard good things about Linux, I think I'll pop this install in....
btrfs, xfs, reiserfs, ext3, ext4, etc.. mean nothing to the user and if he says, "hmm.., this btrfs is at the front of the list, it must be the most reliable, I'll try it"... Watch out..
I have never, in the 17 years I've worked with Linux, seen so many FS failures with data loss as I've seen in the past 12 months related to btrfs. My recommendation to both file here and upstream is exactly what need to be done to move development along, and if the folks on Factory are aware of these failures, then the installer should be adjusted or a warning added that btrfs is under development and should not be used for production installs. That's not chicken little, that just smart.
It will get there I'm sure, but until it does, and at least until the issues with snapshot space exhaustion are fixed and *validated*, it should only be offered as an experimental FS.
Like David, I have over 20 years experience using linux and have become appalled at the development model of the last few years. SuSE stood for quality when I first stated using it (1998) and now (to me) it has become a test bed with the mentality that if you don't like what we force upon you go somewhere else for your linux needs. When my choice of how to build MY linux system is taken away I will then move to another distro. And I refuse to use BTRFS until I stop hearing/reading reports of users disk filling up and or crashing with recovery possible.
Meant to say "with NO recovery possible".
ditto. I've begun moving my systems and those I care for (for pay) from OpenSUSE and it's variants (including SLES/SLED) to other distributions. It's painful, but necessary. Stability is paramount for me to be credible. The Suse line is no longer stable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/05/2015 17:29, Bruce Ferrell a écrit :
ditto. I've begun moving my systems and those I care for (for pay) from OpenSUSE and it's variants (including SLES/SLED) to other distributions. It's painful, but necessary. Stability is paramount for me to be credible. The Suse line is no longer stable.
I happen to fix twice a month various computers, very few with openSUSE, and I can say all the distributions have some problem on time... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 10:36 AM, jdd wrote:
Le 04/05/2015 17:29, Bruce Ferrell a écrit :
ditto. I've begun moving my systems and those I care for (for pay) from OpenSUSE and it's variants (including SLES/SLED) to other distributions. It's painful, but necessary. Stability is paramount for me to be credible. The Suse line is no longer stable.
I happen to fix twice a month various computers, very few with openSUSE, and I can say all the distributions have some problem on time...
jdd
I've been caring for systems since the early 80s. Systems DO break. patches, updates and upgrades aren't supposed to to that. Basic functionality has historically been tested. If a web server is included, it should actually server web pages correctly. When such an error is detected the response should NOT be, "use something else". When Suse was a boxed product, I paid money to buy it for each new release. It was a high quality, rich environment and I had no problem paying for that and recommending it to my employers, colleagues and clients. In the last few years, it has become a sandbox... The kind the kitty uses, full of unpleasant surprises. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 01:36 PM, jdd wrote:
Le 04/05/2015 17:29, Bruce Ferrell a écrit :
ditto. I've begun moving my systems and those I care for (for pay) from OpenSUSE and it's variants (including SLES/SLED) to other distributions. It's painful, but necessary. Stability is paramount for me to be credible. The Suse line is no longer stable.
I happen to fix twice a month various computers, very few with openSUSE, and I can say all the distributions have some problem on time...
I used to. I don't any more. Since some radical Christian objected to one of my random DotSigQuotes I've kept to using the one below on this list since it seem only a little bit controversial. We don't have many top-posters here :-) However one of the ones in the database reads: At least when humans go to casualty, they generally haven't gone into the Control Panel and messed with the settings... I found that people who came to me for advice or fixes either ignored the advice (usually in ways that made them vulnerable), or reversed changes or opened up their firewalls or worse. Sometimes they blamed me. At least when they bitch at me for NOT helping them they can't validly accuse me giving bad advice or breaking their computer. -- 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 04/05/2015 17:19, Ken Schneider - openSUSE a écrit :
Meant to say "with NO recovery possible".
* recovery *is* possible and not even difficult, when one kow how (and I have recovered 6 days ago)
* nobody oblige you to instal 13.2 with btrfs, it's only the default choice jdd -- 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-05-04 19:32, jdd wrote:
Le 04/05/2015 17:19, Ken Schneider - openSUSE a écrit :
Meant to say "with NO recovery possible".
* recovery *is* possible and not even difficult, when one kow how (and I have recovered 6 days ago)
* nobody oblige you to instal 13.2 with btrfs, it's only the default choice
That's true. However, I have seen several people come with problems to the forums, with some breakage or other caused by having btrfs, and when asked, they didn't even know they were using it. They just accepted the defaults. I would, in their place. The most frequent problem is the root partition filling up, and the traditional advice to solve this doesn't work. Snapshots, balancing I don't know what, etc. The cause, IMO, is that the root filesystem when using btrfs should be at least 50 GB, and if that is not possible, YaST should default to ext4 instead. On other occasions the filesystem corrupts, fsck doesn't work, and repair becomes very complicated. Few people know how to repair it (I don't). Some of these people then reinstall using ext4. And this is happening specially to beginners and newcomers, which may be scared by these complications and not use Linux again. IMO, btrfs should not be installed for them, because the toolset is not complete and it is hard to help them. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVHsMYACgkQja8UbcUWM1wtGQD/WEGCT5Af9ls6kMD9UA+6l9b+ 6xLh9tvg3DGroM32dxMA/0HDsfBRe7+xdN15VOAbpvpH5uZADn85cniy2w+Zr4u0 =Y7qO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/05/2015 19:47, Carlos E. R. a écrit :
They just accepted the defaults. I would, in their place.
I did
The most frequent problem is the root partition filling up, and the traditional advice to solve this doesn't work.
? yes it do, at least it did for me (remove snapshots, limit the snapshot number) Snapshots, balancing I
don't know what, etc. The cause, IMO, is that the root filesystem when using btrfs should be at least 50 GB, and if that is not possible, YaST should default to ext4 instead.
yast try to give twice as much for root as before, I used to have 20Gb, I have now 40Gb.. not enough. There is obviously a problem. Same for indexes growing up to 20Gb (not a file system problem, then)
On other occasions the filesystem corrupts, fsck doesn't work, and repair becomes very complicated. Few people know how to repair it (I don't).
until now I only had file system corruption when hardware begin to brake, and this what ever the file system is. But it's just me :-(
And this is happening specially to beginners and newcomers, which may be scared by these complications and not use Linux again. IMO, btrfs should not be installed for them, because the toolset is not complete and it is hard to help them.
right now openSUSE is *not* said to be for beginners, however it's the distribution I find the most easy practically for beginners... other distros are worst (do you explain ppa to ubuntu users?). the fact is no distribution have the man power to troubleshoot all. I'm extremely glad to see tumbleweed grow, because it's the way things can be tested extensively, I I will never instal it on a beginners computers. Linux is evolving fast *and have to*, but this is very demanding for our little community of "helpers"... jdd -- 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-05-04 20:12, jdd wrote:
Le 04/05/2015 19:47, Carlos E. R. a écrit :
On other occasions the filesystem corrupts, fsck doesn't work, and repair becomes very complicated. Few people know how to repair it (I don't).
until now I only had file system corruption when hardware begin to brake, and this what ever the file system is. But it's just me :-(
I have seen corruption beyond repair on all filesystem types I have used. Personally, I mean, not hearsay. Starting with FAT somewhere in the eighties. I had corruption in reiserfs, ext3 or 4, reiserfs, xfs... and I found a way to repeatedly corrupt a btrfs
the fact is no distribution have the man power to troubleshoot all. I'm extremely glad to see tumbleweed grow, because it's the way things can be tested extensively, I I will never instal it on a beginners computers.
True.
Linux is evolving fast *and have to*, but this is very demanding for our little community of "helpers"...
Yes. But my point is that YaST should not install btrfs for novices. How to do that, I don't know. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVH7WoACgkQja8UbcUWM1z79gD7B5Vv8fq0PdJHcBAFeJsxS6BU rBYHftkFaE9QAREzSRMA/0NCVUFZoSyQjqDih49xs3y2efTLr09OpG/cc2yLN8HF =CJ6c -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 01:47 PM, Carlos E. R. wrote:
However, I have seen several people come with problems to the forums, with some breakage or other caused by having btrfs, and when asked, they didn't even know they were using it.
They just accepted the defaults. I would, in their place.
maybe its that I'm an engineer at heart or maybe its that I'm just plain curious, but I never 'just accept' anything. OK, so some things like credit cards I can't 'negotiate' terms, but I still read and try to comprehend the agreements. I know how all the devices I won work. I research most of the things I buy beforehand, read the labels on the products at the supermarket. Excessive? I don't think so, not in this day and age. I'm not an Eco-Nit or a anti-GMO protester, just .... Careful. I've found some food additives that I react badly to and avoid them. Sometimes the labels "Low Salt" and "fat Free" are .... Misleading. "Just accept" is what a lot of vendors expect you to do.
The most frequent problem is the root partition filling up,
That has always been the case. Its why I use LVM In the limiting case, if my hard drive fills up totally, LVM will let me extend onto another drive :-)
and the traditional advice to solve this doesn't work.
What 'traditional' advice are you talking about? Some methods work with all file systems: "make sure you have a backup, repartition & reload" is one. How does that 'not work'? You can grow the FS, just like ext4, ReiserFS, XFS, if you can grow the partition. Oh, right, back to LVM :-) And oh yes, I had a nearly full chogged BtrFS root, but rather than bitch and complain here about it, I did something. I grew the LVM partition and I grew the BtrFS. Added another 30G :-) Worked OK. Please not: I did something that was quite reasonable, something I've done with RootFS that have been ReiserFS and Ext4 in the past. And it worked. Wrote
The cause, IMO, is that the root filesystem when using btrfs should be at least 50 GB, and if that is not possible, YaST should default to ext4 instead.
That strikes me as sensible. Hmm looks like its possible to set up autoyast to do that.
On other occasions the filesystem corrupts, fsck doesn't work, and repair becomes very complicated. Few people know how to repair it (I don't).
Well that takes me back to the 1970s and 1980s. Few sysadmins knew how to repair a V6/V7 file system. FSCK could pick up some pieces and put them in the lost+found, just as some versions of fsck can today, but more likely than not any open files, anything since the last sync, was lost. BTDT, learnt a LOT about the V6/V7 FS and how badly it managed metadata. I made some mods to the scheduling algorithm that increased FS integrity but at the cost of performance, then was told to take them out. Isn't that always the case: speed trumps reliability and integrity every time. -- 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-05-04 21:20, Anton Aylward wrote:
On 05/04/2015 01:47 PM, Carlos E. R. wrote:
They just accepted the defaults. I would, in their place.
maybe its that I'm an engineer at heart or maybe its that I'm just plain curious, but I never 'just accept' anything.
But most computer users do. And I, even being an engineer, when installing something new and don't know much about it, I accept that the defaults are sensible. I may spend the time to find out more, or just go ahead with defaults, and i will learn as I go.
The most frequent problem is the root partition filling up,
That has always been the case. Its why I use LVM In the limiting case, if my hard drive fills up totally, LVM will let me extend onto another drive :-)
No, that's not what happens with btrfs. Of course you can add more space when using LVM. But you do know that most people don't use LVM. I don't, for instance.
and the traditional advice to solve this doesn't work.
What 'traditional' advice are you talking about?
Look in /tmp, and /var/log. Find out their sizes. If there are files too big, delete them. With btrfs, you have to check the snapshots as well. And tools like df may not tell the whole truth. You have to use new commands specific for btrfs. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVH9LMACgkQja8UbcUWM1xHfQEAj0Cc8xhYgMlVCmV+qzTetIsa qjIGB138WNlsIYdyyZQBAJmpuuLYJ7s2n8Wvc2L0a3MyYyPnSRP9K1sATRuG7oO2 =aLHL -----END PGP SIGNATURE----- -- 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 04/05/15 23:37, Carlos E. R. wrote: On 2015-05-04 21:20, Anton Aylward wrote:
On 05/04/2015 01:47 PM, Carlos E. R. wrote:
The most frequent problem is the root partition filling up,
That has always been the case. Its why I use LVM In the limiting case, if my hard drive fills up totally, LVM will let me extend onto another drive :-) No, that's not what happens with btrfs. Of course you can add more space when using LVM. But you do know that most people don't use LVM. I don't, for instance.
and the traditional advice to solve this doesn't work.
What 'traditional' advice are you talking about?
Look in /tmp, and /var/log. Find out their sizes. If there are files too big, delete them.
With btrfs, you have to check the snapshots as well. And tools like df may not tell the whole truth. You have to use new commands specific for btrfs.
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers. I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition. barrowhillfarm:~ # btrfs fi show / Label: none uuid: 2a7b14cf-0917-47f8-8379-10679d9f59d8 Total devices 2 FS bytes used 9.36GiB devid 1 size 36.00GiB used 7.03GiB path /dev/sda2 devid 2 size 36.00GiB used 7.03GiB path /dev/sdg2 btrfs-progs v4.0+20150429 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 iEYEARECAAYFAlVIZc8ACgkQ0Sr7eZJrmU5ljQCgh0rOLBuVgob1ly2H1GsV+Guu cFwAnj2tVzEATxpzzLuoxuttrgL4HOmK =E83n -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 05/05/2015 08:40, Bob Williams a écrit :
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers. I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
I did also and it filled... or may be I didn't clean the system enough after that. and there are dayly updates, so snapshot keep growing :-( jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 03:33 AM, jdd wrote:
Le 05/05/2015 08:40, Bob Williams a écrit :
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers. I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
I did also and it filled... or may be I didn't clean the system enough after that.
and there are dayly updates, so snapshot keep growing :-(
I took Bob's "only" to mean that he turned "daily" off as well. -- 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: SHA1 On 05/05/15 13:31, Anton Aylward wrote:
On 05/05/2015 03:33 AM, jdd wrote:
Le 05/05/2015 08:40, Bob Williams a écrit :
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers. I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
I did also and it filled... or may be I didn't clean the system enough after that.
and there are dayly updates, so snapshot keep growing :-(
I took Bob's "only" to mean that he turned "daily" off as well.
That is correct: # create hourly snapshots TIMELINE_CREATE="no" - -- 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 iEYEARECAAYFAlVIudEACgkQ0Sr7eZJrmU6FMACfWz73pYFRxiM/7Ub8BMRPDmsO WcQAnAyFnt4PXsLskFmbo4SYwi+4uRh+ =+PDs -----END PGP SIGNATURE----- -- 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-05-05 14:31, Anton Aylward wrote:
On 05/05/2015 03:33 AM, jdd wrote:
Le 05/05/2015 08:40, Bob Williams a écrit :
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers. I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
I did also and it filled... or may be I didn't clean the system enough after that.
and there are dayly updates, so snapshot keep growing :-(
I took Bob's "only" to mean that he turned "daily" off as well.
But not pre and post updates, which occur daily for jdd - he is maybe using tumbleweed. Me, if I were using btrfs, I would dedicate a large partition, of 100 GB, and leave all the snapshots. I'd want all the whistles, not tuned down features. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVIvYUACgkQja8UbcUWM1z20AD7Buj9i0IeqYGsft/OFlI/TPLK ST3L9Afnl+9yjJBqI34A/3oqHYBmjDbckKIj7po8ywZFRK1UcmoSPEzVe+Sus4o4 =1AHZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 05/05/2015 14:54, Carlos E. R. a écrit :
Me, if I were using btrfs, I would dedicate a large partition, of 100 GB, and leave all the snapshots. I'd want all the whistles, not tuned down features.
qe where asked to use twice the previous size, it's not enough anymore. I use many packman media files, very often recompiled, so: du -shx / 9,3G / btrfs fi show Label: none uuid: 05617c4f-cc09-43a4-9fc7-1de36cdf8c30 Total devices 1 FS bytes used 15.23GiB devid 1 size 40.00GiB used 19.00GiB path /dev/sdb1 Well... I just decided to be very aggressive in the "I don't want snapshots". packman media-related applications changes nearly everyday! this makes snapshots very big. I had to remove all but the last one and run balance with 75% to recalim part of the size. btrfs fi show Label: none uuid: 05617c4f-cc09-43a4-9fc7-1de36cdf8c30 Total devices 1 FS bytes used 12.26GiB devid 1 size 40.00GiB used 15.77GiB path /dev/sdb1 I even set numbers to zero. I will have one full day (a bit more: 1800s) to notice if something goes wrong. After all I never used this snapshot feature in the past... jdd -- 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-05-05 15:41, jdd wrote:
Le 05/05/2015 14:54, Carlos E. R. a écrit :
Well... I just decided to be very aggressive in the "I don't want snapshots". packman media-related applications changes nearly everyday! this makes snapshots very big.
True... Maybe a cron job could purge the part coming from packman more aggressively. No, I do not know how. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVIy+AACgkQja8UbcUWM1yjUwD7BN6vlYu0hOeqHB8tqMSHaiHq ga+BGH7KhxrbuP6ALLQBAIVtTUE1k9PcvwB4VFBX87kToTrqhclE62OjrruNPxFX =ZiC8 -----END PGP SIGNATURE----- -- 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-05-05 08:40, Bob Williams wrote:
With btrfs, you have to check the snapshots as well. And tools like df may not tell the whole truth. You have to use new commands specific for btrfs.
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers.
Maybe, but snapper is only active when "/" is btrfs.
I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
Absolutely. But that's my point, that you had to do something or your partition would fill up.
barrowhillfarm:~ # btrfs fi show / Label: none uuid: 2a7b14cf-0917-47f8-8379-10679d9f59d8 Total devices 2 FS bytes used 9.36GiB devid 1 size 36.00GiB used 7.03GiB path /dev/sda2 devid 2 size 36.00GiB used 7.03GiB path /dev/sdg2
You see? You had to use something that is not "df". Just what I said. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVIvJcACgkQja8UbcUWM1w5fwEAlMFPfxAUIvhjZCYrIZxbdk57 5E7fYkZqRkiaUHT6u3MA/juNOneNj9/PYkckFmy5OVlXPfcipQFB+91KVXgMyEbR =ZOS5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue 05 May 2015 02:50:32 PM CDT, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-05-05 08:40, Bob Williams wrote:
With btrfs, you have to check the snapshots as well. And tools like df may not tell the whole truth. You have to use new commands specific for btrfs.
Snapshots filling up the root partition is not an inherent failure of btrfs, it is due to the snapper configuration provided by the openSUSE packagers.
Maybe, but snapper is only active when "/" is btrfs.
Hi But can be used with others... From http://snapper.io/overview.html - Works with btrfs, ext4 and thin-provisioned LVM volumes Use an ext4 ~/ and use snapper to backup your user....
I have edited my snapper config to only snapshot pre and post updates (no timeline snapshots) and I still have plenty of room in my root partition.
Absolutely. But that's my point, that you had to do something or your partition would fill up.
barrowhillfarm:~ # btrfs fi show / Label: none uuid: 2a7b14cf-0917-47f8-8379-10679d9f59d8 Total devices 2 FS bytes used 9.36GiB devid 1 size 36.00GiB used 7.03GiB path /dev/sda2 devid 2 size 36.00GiB used 7.03GiB path /dev/sdg2
You see? You had to use something that is not "df". Just what I said.
I noticed on 13.1 that the cron job never ran after first install (no idea why) but once I manually ran the snapper clean up all was good. I do wonder if the cron job isn't running to clean things up, plus on an initial install if installing all sorts of bits and pieces they build up quick. To date across four systems I have no issues but only keep 6 numbered snapshots and no timelines. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.39-47-default up 9:53, 3 users, load average: 1.67, 0.66, 0.42 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-05 15:47, Malcolm wrote:
On Tue 05 May 2015 02:50:32 PM CDT, Carlos E. R. wrote:
Maybe, but snapper is only active when "/" is btrfs.
Hi But can be used with others... From http://snapper.io/overview.html
- Works with btrfs, ext4 and thin-provisioned LVM volumes
Ah, yes, true. I should have expressed myself better. Something like openSUSE enables on installation snapper only when using btrfs.
I noticed on 13.1 that the cron job never ran after first install (no idea why) but once I manually ran the snapper clean up all was good. I do wonder if the cron job isn't running to clean things up, plus on an initial install if installing all sorts of bits and pieces they build up quick. To date across four systems I have no issues but only keep 6 numbered snapshots and no timelines.
Well, the logic for the initial install, what yast proposes and does, will have to be adjusted for several releases. Probably. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVIz0wACgkQja8UbcUWM1xCHgD/eF6SkNvMt2ipNwlT3/2cr4nf wmET0WmhSRmCR8cPfkQA/RLL9eUdzzDGbwTd17PR9YPfoDPZRE7uCxNt0D7s1PTi =nrVG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 10:10 AM, Carlos E. R. wrote:
On 2015-05-05 15:47, Malcolm wrote:
On Tue 05 May 2015 02:50:32 PM CDT, Carlos E. R. wrote:
Maybe, but snapper is only active when "/" is btrfs.
Hi But can be used with others... From http://snapper.io/overview.html
- Works with btrfs, ext4 and thin-provisioned LVM volumes
Ah, yes, true. I should have expressed myself better. Something like openSUSE enables on installation snapper only when using btrfs.
yes, the configs file reads: # subvolume to snapshot SUBVOLUME="/" # filesystem type FSTYPE="btrfs" But that FSTYPE could be something else ... So we wold have this happeining with ext4! The issue isn't BtrFS in that case, its snapper. We shouldn't be blaming BtrFS specifically. We may be right in blaming the people who set up this default config, enabling just about everything! -- 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 05/05/15 15:31, Anton Aylward wrote:
On 05/05/2015 10:10 AM, Carlos E. R. wrote:
On 2015-05-05 15:47, Malcolm wrote:
On Tue 05 May 2015 02:50:32 PM CDT, Carlos E. R. wrote:
Maybe, but snapper is only active when "/" is btrfs.
Hi But can be used with others... From http://snapper.io/overview.html
- Works with btrfs, ext4 and thin-provisioned LVM volumes
Ah, yes, true. I should have expressed myself better. Something like openSUSE enables on installation snapper only when using btrfs.
yes, the configs file reads:
# subvolume to snapshot SUBVOLUME="/"
# filesystem type FSTYPE="btrfs"
But that FSTYPE could be something else ...
So we wold have this happeining with ext4! The issue isn't BtrFS in that case, its snapper.
We shouldn't be blaming BtrFS specifically. We may be right in blaming the people who set up this default config, enabling just about everything!
Which is what I just said. - -- 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 iEYEARECAAYFAlVI2tcACgkQ0Sr7eZJrmU4O6ACghBzqyp2pokqBdDI3AAxKGqJC 8SoAn089h/6Lc90Ax2sLs2NX472Y21cq =zPbS -----END PGP SIGNATURE----- -- 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-05-05 16:31, Anton Aylward wrote:
# filesystem type FSTYPE="btrfs"
But that FSTYPE could be something else ...
So we wold have this happeining with ext4! The issue isn't BtrFS in that case, its snapper.
I'm not sure that snapper works as well on ext4 as on btrfs, which was designed for that idea.
We shouldn't be blaming BtrFS specifically. We may be right in blaming the people who set up this default config, enabling just about everything!
Well, that's true. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVI7c0ACgkQja8UbcUWM1zCYAD9GBMSop+SxeqsvSkP2wgTZJQs xhR+FeFLUEiYPAvYuGUA/RhA9p6JUGsOo4BIzbWp65MiQyXG+URjxJtbppOMBlLm =nSDc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 07:31 AM, Anton Aylward wrote:
So we wold have this happeining with ext4! The issue isn't BtrFS in that case, its snapper.
We shouldn't be blaming BtrFS specifically.
Yes we should be blaming Btrfs specifically. These snapshots aren't a function of snapper, it is just the control mechanism. The Snapshots in question are a built in function of BTRFS, the snapshots thus created are not portable. If BTRFS better balanced its trees and was less subject to breakage and disk hogging this might not be an issue. But because Opensuse snapshots the root partition which includes some very volatile sub-partitions, and that volatility results rapid accumulation of disk space ALL out of a shared pool, the problem is compounded. These disk full situations started showing up as early as 2012, on a lot of distros when ever BTRFS was pressed into service. Btrfs snapshots are described to be diffs of just the changes since the prior snapshot. And the prior snapshot is diffs of changes since the one before that. Turtles all the way down. They should be better than most snapshot systems. The problem with this, is if you remove the oldest snapshot you have to roll all the contents forward into the next snapshot just to have a base image somewhere. With a very volatile /tmp included, each snapshot will be much bigger, and the purging of old snapshots more painful. You would expect marginal gains in free space as this trimming of old snapshots progresses, but this seems not to be happening. No clues beyond that, other than we can't absolve btrfs of blame yet. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 04:48 PM, John Andersen wrote:
If BTRFS better balanced its trees
Good point but not the best way of putting it. Having written error correcting disk drivers I know that you can't spend much time in the kernel doing 'disk work'. A thread that balances the kernel as reading and writing proceeds is just that and will impact the user-perceived performance. Perhaps, since other B-tree based file systems seem to manage this, there is a fundamental design problem . There are external balance utilities just as there are FSCK programs for other file systems or de-fragmentation on MS-DOS file systems that need it (and certain archaic and rarely used early UNIX file systems). I'm not saying that BtrFS is "broken by design", but rather that a design decision is a limitation. I consider the fixed number of inodes allocated in the ext[234] file systems, something inherited from the 1970s origins of UNIX and only rectified in ReiserFS and XFS and similar, to be a similar design decision that I see as being a limitation. It doesn't affect day to day performance until the systems stops dead, though. The thing is that you can't really report 'design decision' as bugs, certain not this late in the game. I've tried complaining about fixed inodes in ext4 after running into inode exhaustion, and I was told to "over provision". Now isn't that what is being said about BtrFS? "Disks is cheap, make the file system larger, over 100G..." -- 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 05/05/2015 04:48 PM, John Andersen wrote:
With a very volatile /tmp included, each snapshot will be much bigger, and the purging of old snapshots more painful.
Please see https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_snapper_s... PLEASE NOTE: This is discussing the *DEFAULT* setup. I've added emphasis that addresses the point your raised, John. <quote> As a result, partitions containing snapshots need to be larger than "normal" partitions. The exact amount strongly depends on the number of snapshots you keep and the amount of data modifications. As a rule of thumb you should consider using twice the size than you normally would. </quote> and more specifically <quote> Some directories need to be excluded from snapshots for different reasons. The following list shows all directories that are excluded: Directories that are Excluded from Snapshots /boot/grub2/i386-pc ,/boot/grub2/x86_64-efi, A rollback of the boot loader configuration is not supported. The directories listed above are architecture-specific. The first two directories are present on x86_64 machines, the latter two on IBM POWER and on IBM System z, respectively. /home If /home does not reside on a separate partition, it is excluded to avoid data loss on rollbacks. /opt, /var/opt Third-party products and add-ons usually get installed to /opt. It is excluded to avoid uninstalling these applications on rollbacks. /srv Contains data for Web and FTP servers. It is excluded to avoid data loss on rollbacks. */tmp*, */var/tmp*, /var/crash *All* *directories* *containing* *temporary* *files* *are* *excluded* *from* *snapshots*. /usr/local This directory is used when manually installing software. It is excluded to avoid uninstalling these installations on rollbacks. /var/lib/named Contains zone data for the DNS server. Excluded from snapshots to ensure a name server can operate after a rollback. /var/lib/mailman, /var/spool Directories containing mails or mail queues are excluded to avoid a loss of mails after a rollback. /var/lib/pgqsl Contains PostgreSQL data. /var/log Log file location. Excluded from snapshots to allow log file analysis after the rollback of a broken system. </quote> -- 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 05/05/2015 04:48 PM, John Andersen wrote:
With a very volatile /tmp included, each snapshot will be much bigger, and the purging of old snapshots more painful.
I am unconvinced by the argument that naive idiots are going to install openSuse Linux beside or to replace their MS-Windows system, no matter how dis-satisfied they are with W/8 or W/8 or how alienated they are by W/10. The Computer Press doesn't seem to emphasise openSuse over other versions of Linux, quite the contrary. Perhaps the followers of Steven J. Vaughan-Nichols might move to Mint which he raves about, or ubuntu, which the herd seems to prefer, or even Fedora which he mentions, but openSuse doesn't seem on his radar. http://www.zdnet.com/article/best-linux-desktop-of-2014-linux-mint-17-1/ http://www.zdnet.com/article/coreos-is-bringing-googles-kubernetes-to-the-en... http://www.zdnet.com/pictures/six-clicks-for-beginners-with-ubuntu-15-04-viv... http://www.zdnet.com/article/hands-on-with-ubuntu-15-04/ See also, from similar sources http://www.zdnet.com/article/tips-from-the-frontline-switching-operating-sys... http://www.zdnet.com/article/linux-storage-futures/ http://www.zdnet.com/article/btrfs-hands-on-exploring-the-error-recovery-fea... I don't think Linux is going be the first choice for many, outside 3rd world areas where licensing is an economic issue. http://www.zdnet.com/article/linux-an-operating-system-for-all-ages/ I don't see the technically naive giving up Windows for Linux. Not do I see someone adopting openSuse just because its there, just because Linux was mentioned in an (e-)magazine article. I may be more aggressive than many of the older generation in 'researching', googling and such, but I see using google and wikipedia and the like as a first line of enquiry, and, sadly an authoritative one[1], when it comes to any question. But I don't see people moving to Linux or openSuse without doing some background research, without looking at the options. yea, yea, yea, it us 'know it alls" who breeze though the install without paying much attention. BTDT. Been surprised at what i got, but it was my own fault for not paying attention. It when I do unfamiliar things I pay more attention. [1] Just as an earlier generation did with dictionaries and Britcanica and encyclopaedia entries written by lunatics. http://en.wikipedia.org/wiki/William_Chester_Minor -- 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 05/05/2015 08:50 AM, Carlos E. R. wrote:
Absolutely. But that's my point, that you had to do something or your partition would fill up.
Well, yes and no. As I understand it and once observed, the snapshot algorithm deletes older snapshots when the disk fills. The issue is where is that threshold and how aggressive is the deletion? it may be that you need to install a package and there isn't enough room. Or there was .. Then the "pre-" part of snapper took enough to make it impossible. Is this threshold configurable? Ah # run daily number cleanup NUMBER_CLEANUP="yes" # limit for number cleanup NUMBER_MIN_AGE="1800" NUMBER_LIMIT="5" Err.... Cron job? Wrote -- 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-05-05 15:55, Anton Aylward wrote:
On 05/05/2015 08:50 AM, Carlos E. R. wrote:
Absolutely. But that's my point, that you had to do something or your partition would fill up.
Well, yes and no. As I understand it and once observed, the snapshot algorithm deletes older snapshots when the disk fills.
If the disk is not big enough (and the size was chosen by yast on initial install, or by reading too old howtos and recommendations), it fills up. It does not react that fast, or assumes a bigger disk. In the forum we got several threads with people with non-working system due to a filled up root. Yes, you can adjust the cleanup. Later, after you see the problems. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVI0HYACgkQja8UbcUWM1x8kAD/ZZyev7qefn0ZQnTXjTA+EYyz sOlWHzm+5xlwRD9ikB8A+gIFBK8ri4yafookAL43Uv2ZjHBJWNlsiswcwr3izTh3 =vvoC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 10:32 AM, jdd wrote:
Le 04/05/2015 17:19, Ken Schneider - openSUSE a écrit :
Meant to say "with NO recovery possible".
* recovery *is* possible and not even difficult, when one kow how (and I have recovered 6 days ago)
* nobody oblige you to instal 13.2 with btrfs, it's only the default choice
jdd
Goes without saying, but also _not at all helpful_. Sounds like excuse making. An OS installed by taking all the defaults should result in a secure, safe, and bullet proof system to the maximum extent possible. Its unreasonable to expect new users (to say nothing of us old-timers) to know in advance that there are significant problems with the recommended defaults. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/05/2015 20:25, John Andersen a écrit :
An OS installed by taking all the defaults should result in a secure, safe, and bullet proof system to the maximum extent possible.
and software should never have bugs :-()
Its unreasonable to expect new users (to say nothing of us old-timers) to know in advance that there are significant problems with the recommended defaults.
openSUSE is *not* aimed to newcommers (officially) the fact is no real newcommer can use any operating system without the help of somebody. If people wants help from me (and around me there are many), they better have to like openSUSE :-). that said I help tumbelweed will clean the process and stable release should be really stable jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 11:35 AM, jdd wrote:
openSUSE is *not* aimed to newcommers (officially)
Is there any source for that statement? Is there any warning away of newcomers? Quote OS main landing web page:
Whether you're an experienced Linux developer or an end user just getting started with Linux, there are many ways for you to participate in the openSUSE project.
The three big topic items on the page are Get It Discover It. Create It. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/05/2015 23:37, John Andersen a écrit :
On 05/04/2015 11:35 AM, jdd wrote:
openSUSE is *not* aimed to newcommers (officially)
Is there any source for that statement? Is there any warning away of newcomers?
may be I missed some discussion, because I very clearly remember opensuse for enthousiats/power user that said, no people, even experienced can take a windows 8.1 computer without a bit of learning, not even an android phone, why should openSUSE be different? for example, why are there only two desktops by default on kde? I need at least 8! and the virtual desktops are the feature windows lack the most. It's one of the first thing I show to previous windows users, because I know than after you use them you can no more live without :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/05/2015 05:02 PM, James Knott wrote:
On 05/05/2015 11:59 AM, jdd wrote:
and the virtual desktops are the feature windows lack the most.
Actually, Windows 10 now supports virtual desktops.
Better late than never, -- 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-05-05 17:59, jdd wrote:
for example, why are there only two desktops by default on kde? I need at least 8! and the virtual desktops are the feature windows lack the most.
It's one of the first thing I show to previous windows users, because I know than after you use them you can no more live without :-))
LOL. Yes. When I use Windows 7, I try to use ctrl-alt-right-arrow to switch to the next desktop. WTF! The Windows desktop rotates 90 degrees, instead of going to the next workspace. The first time this happened to me I had to use the phone to google around how to revert the situation, because even the mouse was unusable, it was reverted in strange ways. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVI7tgACgkQja8UbcUWM1yJ9wD+KpVmQMqz8t/hkbRgCvvoO9aR oxVSXDHWg/fxro1XKrkA/R5gx36ijhSHqvqtQWvBYPO//AhplkXrqh8fwSSjktlw =NhUd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/04/2015 11:13 AM, Ken Schneider - openSUSE wrote:
it has become a test bed with the mentality
Excuse me? I always thought that _openSuse_ was the developmental test-bed for the commercial product that is Novell's SLED -- SUSE Linux Enterprise Desktop & SLES -- SUSE Linux Enterprise Server. The latter is also available for IBM's zSeries. Novell bought the SUSE (then "SuSE") brands and trademarks in 2003. Attachemate bought Novell in 2011. I have little doubt that Attachemate/Novell expect their product to make money. Gien that openSuse is 'free' I'm happy toe live with the fact that its supported by by groups like this rather than me personally having to pay Novell. YMMV. Given that I've used quite a number of commercial implementation over UNIX since I began working with it in the mid 1970s, and given that in many of those cases i knew more about UNIX in general ans specifically more about UNIX than the people at the vendor support desk that my employers were pay as part of the support contract, I don't feel short-changed by using 'free' Linux. Given what I've learnt about the hiring and project management practices at many firms and the software development practices I've seen in government and commerce, where low cost and inexperience and LoC productivity is valued over planning, testability and maintainability, the people I see developing for Linux seem remarkable skilled and thoughtful, no matter how quirky their individual personalities. UNIX began as a counter-culture experiment. Through the late 1970s and early 1980s the "Berkeley" extensions were greatly demanded by the people buying boxes in that first microprocessor "boom", never mind that the code was awful, written by students and poorly supported. It was USEFUL! You disagree? Take a look at the original version of VI. The code was HORRIBLE in the extreme! I'll grant you that DMR and crew wrote great stuff, most of it being highly parsimonious. But that was the point. The V6/V7 FS was simple. Inefficient, slow, unreliable and inflexible; but it was only a few hundred lines of code. UNIX was then and continued to be in Bell, eventually becoming PLan9 and more, a test-bed for ideas. Linus started Linux in the same mould. That what we have with openSuse lets people try out mode ideas, contribute new ones, not least of all through the build service, does not surprise me in the least. -- 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 05/04/2015 09:52 AM, Anton Aylward wrote:
I have little doubt that Attachemate/Novell expect their product to make money.
You are one step behind the times. http://www.microfocus.com/about/press/pressreleases/2015/pr06042015.aspx By the way, Microfocus is about the most mercenary greedy company I've ever had to deal with. You can write off SLES/SLED. It will be priced out of the market in short order. However, we are lead to believe that OpenSuse is no longer dependent on or a testbed for SLES. Yet the website clearly says "© 2013 SUSE LLC. All Rights Reserved" at the bottom of each page. So it seems opensuse is now owned by MicroFocus. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 04/05/2015 19:38, John Andersen a écrit :
On 05/04/2015 09:52 AM, Anton Aylward wrote:
I have little doubt that Attachemate/Novell expect their product to make money.
You are one step behind the times. http://www.microfocus.com/about/press/pressreleases/2015/pr06042015.aspx
By the way, Microfocus is about the most mercenary greedy company I've ever had to deal with. You can write off SLES/SLED. It will be priced out of the market in short order.
whales are eating each other. Im not sure I understand what you try to say is the last part :-(
However, we are lead to believe that OpenSuse is no longer dependent on or a testbed for SLES. Yet the website clearly says "© 2013 SUSE LLC. All Rights Reserved" at the bottom of each page. So it seems opensuse is now owned by MicroFocus.
only the trade mark. Of course not the community. AND: * the Richard announcement seems to go on the good side: more open more sources your link says: "In addition to the Micro Focus portfolio, we will have a second, dedicated portfolio focused on SUSE. The Linux market and open source community have unique characteristics and this focus is essential to our commitment to deliver innovative solutions built on SUSE's technology heritage and track record of delivery. " IMHO SUSE is comming a leader in his segment, at least if the document they distributed at SCALE is true (and why shoudn't it be) http://dodin.org/owncloud/index.php/s/jv0RlVpQp68fiEy may be we undervaluate the interest of our community (hope :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, May 4, 2015 at 2:31 PM, jdd
Le 04/05/2015 19:38, John Andersen a écrit :
On 05/04/2015 09:52 AM, Anton Aylward wrote:
I have little doubt that Attachemate/Novell expect their product to make money.
You are one step behind the times. http://www.microfocus.com/about/press/pressreleases/2015/pr06042015.aspx
By the way, Microfocus is about the most mercenary greedy company I've ever had to deal with. You can write off SLES/SLED. It will be priced out of the market in short order.
whales are eating each other. Im not sure I understand what you try to say is the last part :-(
However, we are lead to believe that OpenSuse is no longer dependent on or a testbed for SLES. Yet the website clearly says "© 2013 SUSE LLC. All Rights Reserved" at the bottom of each page. So it seems opensuse is now owned by MicroFocus.
only the trade mark. Of course not the community.
AND:
* the Richard announcement seems to go on the good side: more open more sources
your link says:
"In addition to the Micro Focus portfolio, we will have a second, dedicated portfolio focused on SUSE. The Linux market and open source community have unique characteristics and this focus is essential to our commitment to deliver innovative solutions built on SUSE's technology heritage and track record of delivery. "
IMHO SUSE is comming a leader in his segment, at least if the document they distributed at SCALE is true (and why shoudn't it be)
http://dodin.org/owncloud/index.php/s/jv0RlVpQp68fiEy
may be we undervaluate the interest of our community (hope :-))
jdd
I don't know what's happening recently, but I was consulting at Ford Motor Company 6 or 7 years ago and the only linux they had inhouse was SUSE. They had a number of VMware ESXi clusters setup that could run SUSE VMs. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (17)
-
Anton Aylward -
Bob Williams -
Bruce Ferrell -
Carlos E. R. -
Carlos E. R. -
Daniel Bauer -
David C. Rankin -
Greg Freemyer -
James Knott -
jdd -
John Andersen -
Ken Schneider - openSUSE -
Malcolm -
michael norman -
Rodney Baker -
Ruben -
Stanislav Baiduzhyi