[opensuse] Drive, space and usage
I am upgrading from 500GB to 1TB drives. The 500GB drives are 99% full. After I do the initial upgrade, how is the data spread across the drive ? Contiguous from front to back like Windows FS ? Or evenly spread (but contiguously) across the drive ? Ultimately, I'm trying to figure out - is the front of the drive going to get the brunt of the work or is the data going to be scattered across the drive. General layout: root (/) swap /home (rest of drive) TIA, Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/29/2013 10:49 PM, Duaine Hechler wrote:
I am upgrading from 500GB to 1TB drives. The 500GB drives are 99% full.
After I do the initial upgrade, how is the data spread across the drive ?
Contiguous from front to back like Windows FS ? Or evenly spread (but contiguously) across the drive ?
Ultimately, I'm trying to figure out - is the front of the drive going to get the brunt of the work or is the data going to be scattered across the drive.
General layout: root (/) swap /home (rest of drive)
TIA, Duaine Forgot about the FS I'm using - which is the ReiserFS.
-- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 29 Sep 2013, Duaine Hechler wrote:
On 09/29/2013 10:49 PM, Duaine Hechler wrote:
I am upgrading from 500GB to 1TB drives. The 500GB drives are 99% full.
1TB's not worth the hassle these days. 2TB cost little more. E.g. (as you're in the US) at newegg 1TB costs $70 and up, 2TB for $85 and up, and 3TB for $120 and up. The actual prices may vary, but the scheme (i.e. the relation between 1/2/3TB will be almost the same regardless of the actual vendor). 4TB is still quite unproportionally expensive.
After I do the initial upgrade, how is the data spread across the drive ?
Usually, if you partition the drive, format the partitions and then copy the data onto it, it'll fill the partitions (each) from "front to back".
Ultimately, I'm trying to figure out - is the front of the drive going to get the brunt of the work or is the data going to be scattered across the drive.
Linux FSen generally spread files soon across the whole partition (only on the initial sequential write of files it get's filled from the "front" on) and the metadata is (unlike e.g. FAT's FAT and NTFS' MFT[0]) also spread out and near the data.
General layout: root (/) swap /home (rest of drive)
Forgot about the FS I'm using - which is the ReiserFS.
Dump it. You're riding a dead horse. From WP: | Namesys considered ReiserFS (now occasionally referred to as Reiser3) | stable and feature-complete and, with the exception of security | updates and critical bug fixes, ceased development on it to | concentrate on its successor, Reiser4. Namesys went out of business in | 2008 after Reiser was charged with the murder of his wife. However, | volunteers continue to work on the open source project.[4] And migrating to a new disk is the perfect opportunity to change the filesystem too. I recommend ext3 (can be upgraded to ext4 at any time), much like using 'tune2fs -j' to move from ext2 to ext3 [1], but directly choosing ext4 would be good as well. And SUSE considers the _supported_ feature set of btrfs (as supported in SLES) stable, so that might be an alternative besides ext3/ext4. -dnh [0] not sure if that's still the case, ISTR it was that the MFT had one copy at the start and one at the end of the partition, subjecting those disc regions to more IO. [1] yeah, minus some ext3 features, but a lot of that can be done by other tune2fs operations and mount-options. PS: Actually: I do use reiserfs again. As a loop-mounted newsspool lying on an ext3 like the rest of my stuff (except the SSD, that's ext4) ;) # losetup -a /dev/loop0: [0876]:667931 (/data/spool/news_reiserfs.img) # df -hi ### trimmed /dev/sdh6 1.8M 1.4M 397K 78% /data /dev/loop0 0 0 0 - /data/spool/news # df -Th ### trimmed /dev/sdh6 ext3 1.8T 1.7T 21G 99% /data /dev/loop0 reiserfs 8.0G 5.8G 2.3G 73% /data/spool/news /data is a FS rather tuned to holding large files and not suited for the million(s?) or so inodes needed for my newsspool ;) But I think I'll migrate the spool to a new image with ext4 or btrfs ;) -- How do we persuade new users that spreading fonts across the page like peanut butter across hot toast is not necessarily the route to typographic excellence? -- Peter Flynn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/30/2013 01:33 AM, David Haller wrote:
Hello,
On Sun, 29 Sep 2013, Duaine Hechler wrote:
On 09/29/2013 10:49 PM, Duaine Hechler wrote:
I am upgrading from 500GB to 1TB drives. The 500GB drives are 99% full. 1TB's not worth the hassle these days. 2TB cost little more. E.g. (as you're in the US) at newegg 1TB costs $70 and up, 2TB for $85 and up, and 3TB for $120 and up. The actual prices may vary, but the scheme (i.e. the relation between 1/2/3TB will be almost the same regardless of the actual vendor). 4TB is still quite unproportionally expensive.
After I do the initial upgrade, how is the data spread across the drive ? Usually, if you partition the drive, format the partitions and then copy the data onto it, it'll fill the partitions (each) from "front to back".
Ultimately, I'm trying to figure out - is the front of the drive going to get the brunt of the work or is the data going to be scattered across the drive. Linux FSen generally spread files soon across the whole partition (only on the initial sequential write of files it get's filled from the "front" on) and the metadata is (unlike e.g. FAT's FAT and NTFS' MFT[0]) also spread out and near the data.
General layout: root (/) swap /home (rest of drive)
Forgot about the FS I'm using - which is the ReiserFS. Dump it. You're riding a dead horse. From WP:
| Namesys considered ReiserFS (now occasionally referred to as Reiser3) | stable and feature-complete and, with the exception of security | updates and critical bug fixes, ceased development on it to | concentrate on its successor, Reiser4. Namesys went out of business in | 2008 after Reiser was charged with the murder of his wife. However, | volunteers continue to work on the open source project.[4]
And migrating to a new disk is the perfect opportunity to change the filesystem too. I recommend ext3 (can be upgraded to ext4 at any time), much like using 'tune2fs -j' to move from ext2 to ext3 [1], but directly choosing ext4 would be good as well. And SUSE considers the _supported_ feature set of btrfs (as supported in SLES) stable, so that might be an alternative besides ext3/ext4.
-dnh
[0] not sure if that's still the case, ISTR it was that the MFT had one copy at the start and one at the end of the partition, subjecting those disc regions to more IO.
[1] yeah, minus some ext3 features, but a lot of that can be done by other tune2fs operations and mount-options.
PS: Actually: I do use reiserfs again. As a loop-mounted newsspool lying on an ext3 like the rest of my stuff (except the SSD, that's ext4) ;) # losetup -a /dev/loop0: [0876]:667931 (/data/spool/news_reiserfs.img) # df -hi ### trimmed /dev/sdh6 1.8M 1.4M 397K 78% /data /dev/loop0 0 0 0 - /data/spool/news # df -Th ### trimmed /dev/sdh6 ext3 1.8T 1.7T 21G 99% /data /dev/loop0 reiserfs 8.0G 5.8G 2.3G 73% /data/spool/news
/data is a FS rather tuned to holding large files and not suited for the million(s?) or so inodes needed for my newsspool ;)
But I think I'll migrate the spool to a new image with ext4 or btrfs ;) Currently on 12.2 .......
Ok, when I decided on the use of the Resiserfs, I needed the absolute max use of the drive. And, with ext3, even with journalling, I would ocassinally loose files. Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files. Now, (12.2), is btrfs ? TIA, Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/10/2013 05:51, Duaine Hechler a écrit :
And, with ext3, even with journalling, I would ocassinally loose files.
Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files.
Now, (12.2), is btrfs ?
this is mostly a troll. context dependent, any file system can lose files - and none should I use always ext4 with satisfaction jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2013 01:59 AM, jdd wrote:
Le 02/10/2013 05:51, Duaine Hechler a écrit :
And, with ext3, even with journalling, I would ocassinally loose files.
Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files.
Now, (12.2), is btrfs ?
this is mostly a troll. context dependent, any file system can lose files - and none should
I use always ext4 with satisfaction
jdd
Is btrfs in 12.2 - now considered "stable" yet ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/10/2013 09:16, Duaine Hechler a écrit :
Is btrfs in 12.2 - now considered "stable" yet ?
from a very long previous discussion, I retained that the problem was the missing repair application (fsck?) no idea of the present situation jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd said the following on 10/02/2013 03:20 AM:
Le 02/10/2013 09:16, Duaine Hechler a écrit :
Is btrfs in 12.2 - now considered "stable" yet ?
from a very long previous discussion, I retained that the problem was the missing repair application (fsck?)
no idea of the present situation
As of 12.3 and 3.7.10-1.16 that is still the case. I know there are alter versions in some repositories but cannot speak for that. Yes there are people here using factory and 13.1 trials but I don't know if they use btrfs. Is Duaine trolling? Superficially, yes. As you say, jdd no file system should loose files. Reiser has been the most resilient I've worked with but occasionally fsck ends up putting stuff in /lost+found Duaine: did you look for you lost files in lost+found? -- Guilt was the grease in which the wheels of the authority turned. (Small Gods) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/10/2013 13:49, Anton Aylward a écrit :
As you say, jdd no file system should loose files.
usually I only try not to do the mistake, but it's so common, evry time I wonder what is the rigth word :-) http://www.ross.net/notes/loose.shtml jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2013 09:13 AM, jdd wrote:
usually I only try not to do the mistake, but it's so common, evry time I wonder what is the rigth word :-)
http://www.ross.net/notes/loose.shtml
jdd
Hi-- Here is my favorite. Tom http://public.wsu.edu/~brians/errors/errors.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler <dahechler@att.net> wrote:
Le 02/10/2013 05:51, Duaine Hechler a écrit :
And, with ext3, even with journalling, I would ocassinally loose files.
Now, that I've doubled my drive space, what is the best - supported
On 10/02/2013 01:59 AM, jdd wrote: -
filesystem - that will be the best at NOT losing files.
Now, (12.2), is btrfs ?
this is mostly a troll. context dependent, any file system can lose files - and none should
I use always ext4 with satisfaction
jdd
Is btrfs in 12.2 - now considered "stable" yet ?
No, nor in 12.3. There are RPMs that won't even install if the destination is btrfs. The issue is limited links (hard? / soft?). Also snapper and btrfs have negative interactions in 12.3 that can fill your disk prematurely if you have root or /usr on btrfs. If root is full I think you have to boot to rescue mode to delete excess snapshots when it happens. There is serious discussion on factory of declaring a subset of the btrfs features stable for root usage with 13.1 due out next month. 13.2 may default to btrfs for root on new installs (restricted to the stable features?). Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 10/02/2013 08:35 AM:
Is btrfs in 12.2 - now considered "stable" yet ?
I've been using BtrFS with 12.3 since I installed 12.3 shortly after it came out. Apart from a small swap partition the whole of the disk is one huge great BtrFS partition. There is no separate /boot. All of /var/ /usr /home are in the one huge partition. I figured if BtrFS can optimise then let it optimise the hell out of things :-) It works read good, I've had no disappointments. Yes fsck is missing but I've had no problems.
No, nor in 12.3. There are RPMs that won't even install if the destination is btrfs.
I've not observed this; certainly non of the base packages and certainly none of the media tools I've installed. Rather than just rumours can you give specific examples and I'll see what happens when I try them.
The issue is limited links (hard? / soft?).
I've never heard of that, can you give references please? Oh right, I have a big disk so that's not likely to happen. I suppose on a small partition you can run out of inodes -- which is what limited links really means - even with ext4. I did that with 11.4/ext3 and its one reason I stuck with ReiserFS. File systems might have limits but the idea of setting aside a fixed area for inodes is so ... well V7FS-ish.
Also snapper and btrfs have negative interactions in 12.3 that can fill your disk prematurely if you have root or /usr on btrfs. If root is full I think you have to boot to rescue mode to delete excess snapshots when it happens.
NO! The reality is that snapper is configurable. Once, just once I thought my disk was filling, and saw that it was because snapper was taking backups every time I did a 'zypper up'. I can see how valuable this is in a corporate setting, it means I can back out of specific updates! Fine, but this is my desktop and I don't need that and turned it off. You can too. RTFM. It helps to read the release notes and realise you are getting this and turn it off before you've accumulated about 28G of updates and start thinking WTF? is going on. Stupid me! But this is an incredibly useful feature and filling up the file system is not restricted to BtrFS. Also making root /usr too small is a problem that goes way way back. Its why I recommend using LVM and ReiserFS, or some other FS that can shrink and grow. Not XFS, it can only grow. You may find that you over-estimated a file system and need to scavenge from it to enlarge another FS. And ReiserFS is a b-tree file system so you'll not have to worry about adjusting the inode space...
There is serious discussion on factory of declaring a subset of the btrfs features stable for root usage with 13.1 due out next month.
The issue with BtrFS isn't simply stable/unstable as a binary choice so much as, well I keep pointing out Context is Everything and the issue is "are you going to be operating in one of the unstable areas?" My desktop: browsing; email; some documentation; reading PDF papers; some photo editing; playing a bit of music - nothing very extreme or stressing. Typical desktop for many 'home users'. No problems with BtrFS. Would I recommend it for a high stress development of photo production or music production system? No, but look where the stable and unstable features apply. You may want the large file features of ext4 or XFS. Or is this a netbook/laptop with a SSD? Then yes, BtrFS is the way to go. Context is Everything - never doubt it. And by the way, please can I have the references to the apps that won't load and the mention of running out of links/inodes with BtrFS. Failing that I'm going to consider them unsubstantiated malicious rumours. And as for ReiserFS, don't let the fact that the original designer is jailed for murder. This is a damn good FS and there have been no serious problems with it recently. Its a great example of getting things tight the first time instead of needing to constantly tweak and hack. Compare, with Internet Explorer :-) -- What makes the universe so hard to comprehend is that there's nothing to compare it with. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1310021638120.1095@Telcontar.valinor> On Wednesday, 2013-10-02 at 09:34 -0400, Anton Aylward wrote:
Greg Freemyer said the following on 10/02/2013 08:35 AM:
Apart from a small swap partition the whole of the disk is one huge great BtrFS partition. There is no separate /boot. All of /var/ /usr /home are in the one huge partition. I figured if BtrFS can optimise then let it optimise the hell out of things :-)
The issue with one partition of any type (no /home) is that you can not reinstall the system, typically with a new release, because it means reformatting home and loosing your data.
It works read good, I've had no disappointments.
Yes fsck is missing but I've had no problems.
And if you do have a problem, how will you do an fsck on it? That's the question. Eventually, now, in ten years, you will need it.
The issue is limited links (hard? / soft?).
I have.
I've never heard of that, can you give references please?
+++································ Date: Wed, 04 Sep 2013 12:04:58 -0400 From: Jeff Mahoney <**@suse.com> To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Re: BtrFS as default fs? - - Removal of the strange per-directory hard link limit - Due to the backreferences to a single inode needing to fit in a single file system block, there was a limit to the number of hard links in a single directory. It could be quite low. - Limit removed by adding a new extended inode ref item, not enabled by default yet since it's a disk format change. Extended inode ref only used when required since it's not as space-efficient as the single node item. There's probably room for discussion within the file system community on whether we'd want to add an "ok to change" bit so that file systems have the ability to use the new extended inode ref items when needed but doesn't set the incompat bit until they're actually used. The other side of that coin is that it may not be clear to users when/if their file system has become incompatible with older kernels. ································++- Notice that the improvement needs reformat of the partition.
There is serious discussion on factory of declaring a subset of the btrfs features stable for root usage with 13.1 due out next month.
The issue with BtrFS isn't simply stable/unstable as a binary choice so much as, well I keep pointing out
There are features of btrfs that will be deactivated by default on 13.1, like for example, filessystem compression, because *the devs* do not think it is stable enough.
and the issue is "are you going to be operating in one of the unstable areas?"
I would. Compression is precissely the feature I want.
My desktop: browsing; email; some documentation; reading PDF papers; some photo editing; playing a bit of music - nothing very extreme or stressing. Typical desktop for many 'home users'. No problems with BtrFS.
In that same factory thread there was a link to a speed test of several fileystems, and btrfs was the slowest on some of the tests.
And by the way, please can I have the references to the apps that won't load and the mention of running out of links/inodes with BtrFS. Failing that I'm going to consider them unsubstantiated malicious rumours.
+++································ Date: Thu, 05 Sep 2013 11:42:08 +0200 From: Stephan Kulow <***@suse.de> To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] BtrFS as default fs? At the moment you can't even install factory with btfs as default because of bugs as bnc#835695 ································++- +++································ The bug *is* fixed - https://build.opensuse.org/request/show/198042 And yes, yast should have given an error dialog about the problem - still that the error is there is btrfs' fault. But that problem is fixed too - it's still a problem on updates though. We need to make sure not to use too many hardlinks not to break zypper dups from 12.3 on btrfs. ································++- Read that thread, a lot of issues are discussed.
And as for ReiserFS, don't let the fact that the original designer is jailed for murder. This is a damn good FS and there have been no serious problems with it recently. Its a great example of getting things tight the first time instead of needing to constantly tweak and hack. Compare, with Internet Explorer :-)
You can no longer install openSUSE with it, as it has been removed from the install disk partitioner (13.1) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJMMDcACgkQtTMYHG2NR9UwSwCdGMQdp7aY5iD8iy3uJo9X/BBA LPcAnjfNduGU0TMsAswnuRvW18VxbUgC =jmKn -----END PGP SIGNATURE-----
Carlos E. R. wrote:
- Limit removed by adding a new extended inode ref item, not enabled by default yet since it's a disk format change. Extended inode ref only used when required since it's not as space-efficient as the single node item. There's probably room for discussion within the file system community on whether we'd want to add an "ok to change" bit so that file systems have the ability to use the new extended inode ref items when needed but doesn't set the incompat bit until they're actually used. The other side of that coin is that it may not be clear to users when/if their file system has become incompatible with older kernels. ································++-
Notice that the improvement needs reformat of the partition.
If you read the quote you posted, or any other material about the problem, you will see that solving it does NOT need a reformat. You simply need to run the same FS with an up-to-date kernel. It adjusts automatically if and when needed. -- 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 Wednesday, 2013-10-02 at 15:53 +0100, Dave Howorth wrote:
Carlos E. R. wrote:
- Limit removed by adding a new extended inode ref item, not enabled by default yet since it's a disk format change. Extended inode ref only used when required since it's not as space-efficient as the single node item. There's probably room for discussion within the file system community on whether we'd want to add an "ok to change" bit so that file systems have the ability to use the new extended inode ref items when needed but doesn't set the incompat bit until they're actually used. The other side of that coin is that it may not be clear to users when/if their file system has become incompatible with older kernels. ································++-
Notice that the improvement needs reformat of the partition.
If you read the quote you posted, or any other material about the problem, you will see that solving it does NOT need a reformat. You simply need to run the same FS with an up-to-date kernel. It adjusts automatically if and when needed.
Well, the choice of words "it's a disk format change" is confusing, then. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJNraUACgkQtTMYHG2NR9X7+gCfQ3EMKQ1Md9j/x1dwKH3ilO4d WaYAniX4ImcQp315rN76P6ywGI3JLkV2 =vx0b -----END PGP SIGNATURE-----
On Thu, Oct 3, 2013 at 1:47 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2013-10-02 at 15:53 +0100, Dave Howorth wrote:
Carlos E. R. wrote:
- Limit removed by adding a new extended inode ref item, not enabled by default yet since it's a disk format change. Extended inode ref only used when required since it's not as space-efficient as the single node item. There's probably room for discussion within the file system community on whether we'd want to add an "ok to change" bit so that file systems have the ability to use the new extended inode ref items when needed but doesn't set the incompat bit until they're actually used. The other side of that coin is that it may not be clear to users when/if their file system has become incompatible with older kernels. ································++-
Notice that the improvement needs reformat of the partition.
If you read the quote you posted, or any other material about the problem, you will see that solving it does NOT need a reformat. You simply need to run the same FS with an up-to-date kernel. It adjusts automatically if and when needed.
Well, the choice of words "it's a disk format change" is confusing, then.
Per the factory thread: The "adjusts automatically" statement appears to be wrong. You have to invoke a specific userspace tool to trigger the change. (ie. btrfstune -r <device> will fix this.) The 12.3 kernel can make the disk format change without re-formatting, but it requires the filesystem be unmounted. The 13.1 kernel will allow the format change without unmounting the filesystem. Further, in addition to the filesystem format change, you have to have a new mount option to allow it to be used. Unfortunately the 12.3 Boot DVD does not have a current enough userspace toolset to invoke the change, thus the need for a 13.1 boot media. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On Thu, Oct 3, 2013 at 1:47 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2013-10-02 at 15:53 +0100, Dave Howorth wrote:
Carlos E. R. wrote:
- Limit removed by adding a new extended inode ref item, not enabled by default yet since it's a disk format change. Extended inode ref only used when required since it's not as space-efficient as the single node item. There's probably room for discussion within the file system community on whether we'd want to add an "ok to change" bit so that file systems have the ability to use the new extended inode ref items when needed but doesn't set the incompat bit until they're actually used. The other side of that coin is that it may not be clear to users when/if their file system has become incompatible with older kernels. ································++-
Notice that the improvement needs reformat of the partition.
If you read the quote you posted, or any other material about the problem, you will see that solving it does NOT need a reformat. You simply need to run the same FS with an up-to-date kernel. It adjusts automatically if and when needed.
Well, the choice of words "it's a disk format change" is confusing, then.
Per the factory thread:
The "adjusts automatically" statement appears to be wrong. You have to invoke a specific userspace tool to trigger the change. (ie. btrfstune -r <device> will fix this.)
No, the btrfstune is to enable the option; that is only disabled by the powers-that-be. In a mainstream kernel, its already enabled. So if you're running an up-to-date kernel, as I stated, and not an old SUSE kernel like 12.3, the process is automatic. When the option is enabled, the kernel decides automatically when and if it needs to make the change (go to extended refs). It most certainly does not require a reformat.
The 12.3 kernel can make the disk format change without re-formatting, but it requires the filesystem be unmounted.
The 13.1 kernel will allow the format change without unmounting the filesystem.
Further, in addition to the filesystem format change, you have to have a new mount option to allow it to be used.
Unfortunately the 12.3 Boot DVD does not have a current enough userspace toolset to invoke the change, thus the need for a 13.1 boot media.
Greg
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-10-02 16:39 (GMT+0200) Carlos E. R. composed:
The issue with one partition of any type (no /home) is that you can not reinstall the system, typically with a new release, because it means reformatting home and loosing your data.
Technically incorrect, except WRT installers that refuse to let installation proceed without first formatting / (e.g. Fedora). One can boot something else, delete the package management data and the binaries (/bin/, /lib/, /run/, /sys/, /var/, etc.), but save /home/ and selected config files (in /etc/), then perform an installation. Reformatting / isn't necessary with openSUSE. Just be forewarned that leaving inappropriate files or config settings behind is is a formula for inexplicable and/or undesirable behavior in the new installation. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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 Wednesday, 2013-10-02 at 11:10 -0400, Felix Miata wrote:
On 2013-10-02 16:39 (GMT+0200) Carlos E. R. composed:
The issue with one partition of any type (no /home) is that you can not reinstall the system, typically with a new release, because it means reformatting home and loosing your data.
Technically incorrect, except WRT installers that refuse to let installation proceed without first formatting / (e.g. Fedora). One can boot something else, delete the package management data and the binaries (/bin/, /lib/, /run/, /sys/, /var/, etc.), but save /home/ and selected config files (in /etc/), then perform an installation. Reformatting / isn't necessary with openSUSE. Just be forewarned that leaving inappropriate files or config settings behind is is a formula for inexplicable and/or undesirable behavior in the new installation.
That's an interesting procedure... undocumented, though (at openSUSE). - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJNrg0ACgkQtTMYHG2NR9WF/wCeJjIKFN4/EwDIfAaPx/P/pf++ abkAmgMBglSCj/fcuvENF8mLHIeSA+8j =RDWh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-10-03 19:49 (GMT+0200) Carlos E. R. composed:
On Wednesday, 2013-10-02 at 11:10 -0400, Felix Miata wrote:
On 2013-10-02 16:39 (GMT+0200) Carlos E. R. composed:
The issue with one partition of any type (no /home) is that you can not reinstall the system, typically with a new release, because it means reformatting home and loosing your data.
Technically incorrect, except WRT installers that refuse to let installation proceed without first formatting / (e.g. Fedora). One can boot something else, delete the package management data and the binaries (/bin/, /lib/, /run/, /sys/, /var/, etc.), but save /home/ and selected config files (in /etc/), then perform an installation. Reformatting / isn't necessary with openSUSE. Just be forewarned that leaving inappropriate files or config settings behind is is a formula for inexplicable and/or undesirable behavior in the new installation.
That's an interesting procedure... undocumented, though (at openSUSE).
There's special magic it its regard with openSUSE. YaST is both operating configurator, and installer. So, it's rather smart WRT appropriate handling of any existing config files it finds during installation, in particular among them, /etc/HOSTNAME, /etc/exports, /etc/udev/rules.d/70-persistent-net.rules, /etc/samba/smb.conf, /etc/hosts, /etc/resolv.conf, /etc/zypp/repos.d/ and others. The result can be rather like a time-saving fresh install/upgrade hybrid. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-10-04 a las 12:40 -0400, Felix Miata escribió:
That's an interesting procedure... undocumented, though (at openSUSE).
There's special magic it its regard with openSUSE. YaST is both operating configurator, and installer. So, it's rather smart WRT appropriate handling of any existing config files it finds during installation, in particular among them, /etc/HOSTNAME, /etc/exports, /etc/udev/rules.d/70-persistent-net.rules, /etc/samba/smb.conf, /etc/hosts, /etc/resolv.conf, /etc/zypp/repos.d/ and others. The result can be rather like a time-saving fresh install/upgrade hybrid.
Those files are also used if you format-install. Fstab and password are noticiable. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlJP2BEACgkQja8UbcUWM1wcZgD/UUAd2y/skxq4huMVGuj7VxHj viRLrjpOChGJp5MhjzMA/2+aERro9DJ/mIS/FlRf6G9InzKAV4I7/QHvgUNywuUN =GMrU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Wed, 2 Oct 2013 16:39:44 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
The issue with one partition of any type (no /home) is that you can not reinstall the system, typically with a new release, because it means reformatting home and loosing your data.
Oh, tell it those who are using Solaris. You can have unlimited amount of different OS instances of different versions in the same pool. This just needs installer support that's all. And not really big amount of changes, just reasonable design of subvolume namespace. Integration with software management (Solaris 11 had this from day one) had been additional bonus. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJMQQAACgkQR6LMutpd94y+CgCgji1UqWhtVhXHXoLPk2ZJ8m6q GX4AoLgPj4jiTRWh7aAkdqHyDe2wqiAE =Yxtv -----END PGP SIGNATURE-----
On Wed, Oct 2, 2013 at 9:34 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
Greg Freemyer said the following on 10/02/2013 08:35 AM:
Is btrfs in 12.2 - now considered "stable" yet ?
I've been using BtrFS with 12.3 since I installed 12.3 shortly after it came out. Apart from a small swap partition the whole of the disk is one huge great BtrFS partition. There is no separate /boot. All of /var/ /usr /home are in the one huge partition. I figured if BtrFS can optimise then let it optimise the hell out of things :-)
It works read good, I've had no disappointments.
Yes fsck is missing but I've had no problems.
No, nor in 12.3. There are RPMs that won't even install if the destination is btrfs.
I've not observed this; certainly non of the base packages and certainly none of the media tools I've installed. Rather than just rumours can you give specific examples and I'll see what happens when I try them.
The issue is limited links (hard? / soft?).
I've never heard of that, can you give references please?
As Carlos said the whole thread is worth reading: http://markmail.org/message/b5zmpqluenaq4fi5 The bug in question for failed RPM install is: https://bugzilla.novell.com/show_bug.cgi?id=835695 I don't know about you, but it seems very strange that a filesystem has a feature that has to be "enabled" before ImageMagick's rpm can be installed. It looks like openSUSE is considering that feature stable enough to enable it by default for 13.1, but I doubt 12.3 ever gets that mount option by default. Note: you can use btrfstune to enable the relatively new extrefs feature.
Oh right, I have a big disk so that's not likely to happen. I suppose on a small partition you can run out of inodes -- which is what limited links really means - even with ext4. I did that with 11.4/ext3 and its one reason I stuck with ReiserFS. File systems might have limits but the idea of setting aside a fixed area for inodes is so ... well V7FS-ish.
It's not a inode issue. Here's a 4-year thread that discusses it. The default limit is around 300 hardlinks in a single directory. http://thread.gmane.org/gmane.comp.file-systems.btrfs/3427 The new extrefs feature solves that but at least for now is not a always available filesystem feature.
Also snapper and btrfs have negative interactions in 12.3 that can fill your disk prematurely if you have root or /usr on btrfs. If root is full I think you have to boot to rescue mode to delete excess snapshots when it happens.
NO! The reality is that snapper is configurable. Once, just once I thought my disk was filling, and saw that it was because snapper was taking backups every time I did a 'zypper up'. I can see how valuable this is in a corporate setting, it means I can back out of specific updates!
Fine, but this is my desktop and I don't need that and turned it off. You can too. RTFM. It helps to read the release notes and realise you are getting this and turn it off before you've accumulated about 28G of updates and start thinking WTF? is going on. Stupid me!
I believe there are 2 issues: 1) df used to show disk free and included the snapshots as part of freespace. That is simply wrong because df would show space, but you could not create files. Has it been fixed in 12.2 / 12.3 / 13.1? (I don't have btrfs on my laptop currently so I don't know.) 2) snapper's default config keeps way too many snapshots in 12.3 and before. For 13.1 they are reducing the default number kept.
But this is an incredibly useful feature and filling up the file system is not restricted to BtrFS.
Here's a btrfs FALSE filesystem full bug that has not been resolved in 12.3: https://bugzilla.novell.com/show_bug.cgi?id=828229 Note it started reporting full when only about 9 TB of the 17 TB had been written. This does not appear to be a snapshot issue, but some other btrfs kernel bug. Take a look at bugzilla: https://bugzilla.novell.com/buglist.cgi?quicksearch=btrfs 24 open bugs related to btrfs. It might be usable by many for a lot of circumstances, but to say it is stable in 12.3 and before is just not accurate. And even if the kernel is deemed stable for 13.1, then there is the userspace tools that need updates to work well with btrfs underlying them. Based on the factory thread I suspect btrfs will be made the default install filesystem for 13.2 and a raft of new bugs and fixes will be going into 13.2 fyi: 13.1 has already been branched off of factory and factory has been at least to some extent unfrozen and is accepting updates destined for 13.2. Major changes are still not welcome in factory for now. I don't know if changing the default install filesystem would be acceptable now or not. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 10/02/2013 12:08 PM:
On Wed, Oct 2, 2013 at 9:34 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
I've never heard of that, can you give references please?
As Carlos said the whole thread is worth reading: http://markmail.org/message/b5zmpqluenaq4fi5
The bug in question for failed RPM install is: https://bugzilla.novell.com/show_bug.cgi?id=835695
I don't know about you, but it seems very strange that a filesystem has a feature that has to be "enabled" before ImageMagick's rpm can be installed. It looks like openSUSE is considering that feature stable enough to enable it by default for 13.1, but I doubt 12.3 ever gets that mount option by default.
I'm thinking that some people involved in this thread haven't paid attention. I've certainly installed ImageMagic * on BtrFS * without having to adjust the parameters but as Greg goes on to say
Here's a 4-year thread that discusses it. The default limit is around 300 hardlinks in a single directory.
it strikes me as strange that a package needs to set up more than 300 hard links in a single directory.
Note: you can use btrfstune to enable the relatively new extrefs feature.
I didn't know about that when I installed Imagemagick. Why didn't I have that problem? As I said, this was btrFS with 12.3, new drive. This is the 3.6 kernel here, not the 'its in 3.7 already' in the bug report.
The new extrefs feature solves that but at least for now is not a always available filesystem feature.
So why didn't it happen to me? Perhaps because I have this huge single BtrFS partition.
It's not a inode issue.
A short while ago we did have "an inode issue". A user was running net news and his system was saying no more space even though df reported much free space. It turened out he was using ext3 or 4 and formatted with defaults. Net news has lots of small files and needs a different inode-to-space ratio. Now you can't remount an ext FS and solve that one! This fixed ratio is a piece of idiocy that dates back to the V6/V7 days Why do I mention it here and now. because in my true 'context is everything' mode I pointed out that in a context where you don't know a b-tree Fs like reiserFS is a better solution. Dealing with network speeds write performance isn't critical, but dealing with many feeds and write-one/read-many read is. Of course YMMV, or "Context is Everything". So lets slag off on the extFS family as well since it has deficiencies. And its had them for longer than BtrFS has existed.
Also snapper and btrfs have negative interactions in 12.3 that can fill your disk prematurely if you have root or /usr on btrfs. If root is full I think you have to boot to rescue mode to delete excess snapshots when it happens.
NO! The reality is that snapper is configurable. Once, just once I thought my disk was filling, and saw that it was because snapper was taking backups every time I did a 'zypper up'. I can see how valuable this is in a corporate setting, it means I can back out of specific updates!
Fine, but this is my desktop and I don't need that and turned it off. You can too. RTFM. It helps to read the release notes and realise you are getting this and turn it off before you've accumulated about 28G of updates and start thinking WTF? is going on. Stupid me!
I believe there are 2 issues:
1) df used to show disk free and included the snapshots as part of freespace. That is simply wrong because df would show space, but you could not create files. Has it been fixed in 12.2 / 12.3 / 13.1? (I don't have btrfs on my laptop currently so I don't know.)
It must have been fixed. I was seeing 'df' reporting a 'nearly out of space' in this huge drive. When I looked in detail it was all under the root level snapshot. That's what made me look into the matter. I can't see why df would not report this space. It reports space taken by other dotted 'hidden' files. Now du is different.
2) snapper's default config keeps way too many snapshots in 12.3 and before. For 13.1 they are reducing the default number kept.
Again, that's configurable. - The snapshots are like with a database, you can do both before and after imaging. - The cleanup runs from a cron job and has a number of different strategies. - certain programs such as yast and zypper make snapshots when they change the system. I find this very important in a production setting, but pretty irrelevant on my desktop/laptop.
But this is an incredibly useful feature and filling up the file system is not restricted to BtrFS.
Here's a btrfs FALSE filesystem full bug that has not been resolved in 12.3:
https://bugzilla.novell.com/show_bug.cgi?id=828229
Note it started reporting full when only about 9 TB of the 17 TB had been written. This does not appear to be a snapshot issue, but some other btrfs kernel bug.
I can't reproduce that, the largest FS I can do is 2T.
Take a look at bugzilla:
https://bugzilla.novell.com/buglist.cgi?quicksearch=btrfs
24 open bugs related to btrfs.
And actually some of those are like this https://bugzilla.novell.com/show_bug.cgi?id=787082 BtrFS is showing up bugs elsewhere. Of course its BtrFS's "fault" that timing problems occur elsewhere</irony>
It might be usable by many for a lot of circumstances, but to say it is stable in 12.3 and before is just not accurate. And even if the kernel is deemed stable for 13.1, then there is the userspace tools that need updates to work well with btrfs underlying them.
Lets face it, the same generalizations can be made about a lot of things we use, not just Linux file systems. We occasionally have people turn up saying that they live by just one file system and its so glorious. Bah Humbug! Context is Everything. But back when, in the V6, V7 and SCO days when we had just the V7FS and the Berkeley Fast File System then fiddling with the calculations of how much space to devote to inodes at installation was a major pain. I remember doing the root and /usr/{lib,bin} measurements over and overand being so thankful than /home was introduced so I could lock down the "installed" part of the OS. We didn't have almost daily updates back then. You lived with bugs for a long time. PAIN PAIN PAIN.
Based on the factory thread I suspect btrfs will be made the default install filesystem for 13.2 and a raft of new bugs and fixes will be going into 13.2
Well that is one way to force the developers to work on it!
fyi: 13.1 has already been branched off of factory and factory has been at least to some extent unfrozen and is accepting updates destined for 13.2. Major changes are still not welcome in factory for now. I don't know if changing the default install filesystem would be acceptable now or not.
So, what kernel? 3.8? 3.10 Or 3.12 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
So, what kernel? 3.8? 3.10 Or 3.12 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk
3.11 is the kernel for 13.1 unless something goes horribly wrong. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 10/02/2013 04:52 PM:
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
So, what kernel? 3.8? 3.10 Or 3.12 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk
3.11 is the kernel for 13.1 unless something goes horribly wrong.
^ +------- That's an odd number. I real thought releases were even numbered. And test releases were odd numbered. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
3.11 is the kernel for 13.1 unless something goes horribly wrong.
^ +------- That's an odd number.
According to Linus, it's "Linux for Workgroups". ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Oct 2, 2013 at 5:06 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
Greg Freemyer said the following on 10/02/2013 04:52 PM:
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
So, what kernel? 3.8? 3.10 Or 3.12 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ2MDk
3.11 is the kernel for 13.1 unless something goes horribly wrong.
---- ^ +------- That's an odd number. I real thought releases were even numbered. And test releases were odd numbered.
That was true of 2.3 back in the last century and 2.5 about 10 years ago. As of 3.0 in particular Linus has said version numbers mean nothing. They have a release every 2 or 3 months and all of them are supposed to be good. Once in a while one is designated as a long term support kernel and releases like SUSE tend to sync into them. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
Greg Freemyer said the following on 10/02/2013 12:08 PM:
On Wed, Oct 2, 2013 at 9:34 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
I've never heard of that, can you give references please?
As Carlos said the whole thread is worth reading: http://markmail.org/message/b5zmpqluenaq4fi5
The bug in question for failed RPM install is: https://bugzilla.novell.com/show_bug.cgi?id=835695
I don't know about you, but it seems very strange that a filesystem has a feature that has to be "enabled" before ImageMagick's rpm can be installed. It looks like openSUSE is considering that feature stable enough to enable it by default for 13.1, but I doubt 12.3 ever gets that mount option by default.
I'm thinking that some people involved in this thread haven't paid attention.
I've certainly installed ImageMagic * on BtrFS * without having to adjust the parameters
but as Greg goes on to say
Here's a 4-year thread that discusses it. The default limit is around 300 hardlinks in a single directory.
it strikes me as strange that a package needs to set up more than 300 hard links in a single directory.
Note: you can use btrfstune to enable the relatively new extrefs feature.
I didn't know about that when I installed Imagemagick. Why didn't I have that problem? As I said, this was btrFS with 12.3, new drive. This is the 3.6 kernel here, not the 'its in 3.7 already' in the bug report.
The new extrefs feature solves that but at least for now is not a always available filesystem feature.
So why didn't it happen to me? Perhaps because I have this huge single BtrFS partition.
I think ImageMagick for 13.1 is different from the one for 12.3. Only the one for 13.1 fails to install due to the BtrFS lack of functionality. Here's a brand new thread from factory today: http://markmail.org/message/vbfiw6sximwukofc As of that 3 hour old thread, there is not even a recommended upgrade path for people running 12.3 with btrfs as their system drive and having ImageMagick installed. That means you are exactly the person that will see this zypper dup upgrade failure unless you happened to have already setup the new feature. Notice the that 12.3 kernel can't setup the feature with the filesystem mounted, so at least as of this very second the only choice is to boot a rescue CD/DVD and make the filesystem change, then boot back. Trouble is the 12.3 boot CD/DVD doesn't have userland tools that allow the feature to be enabled. I'm guessing a 13.1 boot CD could be used. Thus as of this minute, the only option for this use case is to download the 13.1 boot CD / DVD and use it to do the upgrade. I assume this will be resolved in the next few weeks, but 13.1 is rapidly approaching release, so they don't have a lot of time left to address it. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 10/02/2013 05:10 PM:
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
So why didn't it happen to me? Perhaps because I have this huge single BtrFS partition.
I think ImageMagick for 13.1 is different from the one for 12.3. Only the one for 13.1 fails to install due to the BtrFS lack of functionality.
That doesn't make sense. If 13.1 has a late model btrFS with the workaround patch, then it shouldn't fail, and according to that logic its a problem with imagemagick being changed and necessitating that BtrFS doesn't have the fix. There's something there that doesn't make sense.
Here's a brand new thread from factory today:
http://markmail.org/message/vbfiw6sximwukofc
As of that 3 hour old thread, there is not even a recommended upgrade path for people running 12.3 with btrfs as their system drive and having ImageMagick installed.
As of that thread they are running 3.11.0-rc4-7.g327e5fc-default Which gets back to my question about which kernel will be in 13.1 if, as in the past, the .1 (or previously the .0) release is rally a late model beta - call it a delta or a gamma, and the real release is the .2, then yes, sure, its all stuff that we don't expect to work properly anyway... user driven testing. You want a laugh? run find /usr -links +20 -print0 | xargs -0 ls -l | more When you see some link numbers above 200 go past stop and wonder what package they are from. Ask yourself if the installer will install THAT package. If the problem is what you claim then ImageMagick is the least of you worries. If you can install the basic system with that hugely linked file then perhaps the problem is something else.
That means you are exactly the person that will see this zypper dup upgrade failure unless you happened to have already setup the new feature.
I very much doubt I will face that problem for a variety of reasons which should be apparent to most people reading this thread. Hint: its a show-stopper so will be fixed
Notice the that 12.3 kernel can't setup the feature with the filesystem mounted, so at least as of this very second the only choice is to boot a rescue CD/DVD and make the filesystem change, then boot back.
I very much doubt that the 12.3 release will have the 3.11 kernel
Thus as of this minute,
Thank you for the qualifier :-)
the only option for this use case is to download the 13.1 boot CD / DVD and use it to do the upgrade.
I assume this will be resolved in the next few weeks, but 13.1 is rapidly approaching release, so they don't have a lot of time left to address it.
Deadlines can be a great incentive for productivity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-10-02 23:32, Anton Aylward wrote:
Greg Freemyer said the following on 10/02/2013 05:10 PM:
There's something there that doesn't make sense.
It happens on upgrades, not installs. Upgrade of 12.3 to 13.1 means the filsystem is "old" till after the upgrade, but to upgrade you have to install the problem package... -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Anton Aylward <opensuse@antonaylward.com> wrote:
Greg Freemyer said the following on 10/02/2013 05:10 PM:
On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
So why didn't it happen to me? Perhaps because I have this huge single BtrFS partition.
I think ImageMagick for 13.1 is different from the one for 12.3. Only the one for 13.1 fails to install due to the BtrFS lack of functionality.
That doesn't make sense. If 13.1 has a late model btrFS with the workaround patch, then it shouldn't fail, and according to that logic its a problem with imagemagick being changed and necessitating that BtrFS doesn't have the fix.
There's something there that doesn't make sense.
The zipper duplicate upgrade process runs under 12.3. 13.1 doesn't show up until reboot.
Here's a brand new thread from factory today:
http://markmail.org/message/vbfiw6sximwukofc
As of that 3 hour old thread, there is not even a recommended upgrade path for people running 12.3 with btrfs as their system drive and having ImageMagick installed.
As of that thread they are running 3.11.0-rc4-7.g327e5fc-default Which gets back to my question about which kernel will be in 13.1
The answer is still 3.11.
if, as in the past, the .1 (or previously the .0) release is rally a late model beta - call it a delta or a gamma, and the real release is the .2, then yes, sure, its all stuff that we don't expect to work properly anyway... user driven testing.
For the kernel that numbering scheme hasn't been used since 2.6.0 a decade or so ago.
You want a laugh? run
find /usr -links +20 -print0 | xargs -0 ls -l | more
When you see some link numbers above 200 go past stop and wonder what package they are from. Ask yourself if the installer will install THAT
package.
If the problem is what you claim then ImageMagick is the least of you worries. If you can install the basic system with that hugely linked file then perhaps the problem is something else.
I'm not claiming anything, just passing on info from the factory list.
That means you are exactly the person that will see this zypper dup upgrade failure unless you happened to have already setup the new feature.
I very much doubt I will face that problem for a variety of reasons which should be apparent to most people reading this thread.
Hint: its a show-stopper so will be fixed
Easier said than done in this case. It's a chicken and egg problem. With time they could have zipper duplicate upgrade the kernel first then reboot. I doubt they can transparently fix it. The easy option is to not support zipper duplicate for people that have their system files on btrfs. Just require people with that setup to download the dvd and upgrade that way.
Notice the that 12.3 kernel can't setup the feature with the filesystem mounted, so at least as of this very second the only choice is to boot a rescue CD/DVD and make the filesystem change, then boot back.
I very much doubt that the 12.3 release will have the 3.11 kernel
Thus as of this minute,
Thank you for the qualifier :-)
the only option for this use case is to download the 13.1 boot CD / DVD and use it to do the upgrade.
I assume this will be resolved in the next few weeks, but 13.1 is rapidly approaching release, so they don't have a lot of time left to address it.
Deadlines can be a great incentive for productivity.
After some thought I bet they don't support zypper dup updates for users like you. There is time to put a check in zypper to error out cleanly and the user base affected is likely small. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 10/02/2013 11:23 PM:
There's something there that doesn't make sense.
The zipper duplicate upgrade process runs under 12.3. 13.1 doesn't show up until reboot.
Ah! Enlightenment! Thank you! .... but what about ... oh never mind.
For the kernel that numbering scheme hasn't been used since 2.6.0 a decade or so ago.
That long, eh? How time flies when you're having fun with Linux? *sigh* I thought it was a good idea ....
You want a laugh? run
find /usr -links +20 -print0 | xargs -0 ls -l | more
When you see some link numbers above 200 go past stop and wonder what package they are from. Ask yourself if the installer will install THAT package.
No really, try that. If this really is a problem then ImageMagick is the elast of the problems.
Deadlines can be a great incentive for productivity.
After some thought I bet they don't support zypper dup updates for users like you. There is time to put a check in zypper to error out cleanly and the user base affected is likely small.
Maybe, maybe not. I think you can't simply discount the people who upgrade via zypper dup/change repository. -- 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, Oct 3, 2013 at 8:09 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
find /usr -links +20 -print0 | xargs -0 ls -l | more
I don't think the issue triggers if the link is for .. otherwise you could not have a directory with more than 300 subdirectories. So I'm looking only at files and I changed it to +200 links to have less for me to scan: find /usr -type f -links +200 -print0 | xargs -0 ls -l | more On my 12.3 system, I have 518 files output by that. They are all in /usr/lib/locale. The 518 appears to really only be one file linked to 250 names and another file linked to 268 names. The limit is "around 300" so apparently neither of those are causing problems when users have been testing the zypper dup upgrade to 13.1. I doubt many btrfs for root upgrades via zypper dup to 13.1 have been tested yet. This bug is just now getting attention on the factory list. One person proposed switching from hardlinks to symbolic links. I hope they don't go that way as they won't be able to undo the decision for a while. Also they have somehow ensure every package that has the problem is converted to use symbolic links. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
One person proposed switching from hardlinks to symbolic links. I hope they don't go that way as they won't be able to undo the decision for a while. Also they have somehow ensure every package that has the problem is converted to use symbolic links.
Oh right, a file system had a problem that they've now cured. It leads to a migration issue which may be a temporary problem for a few users. So somebody proposes permanently changing the design of a whole bunch of applications, with who knows what ramifications elsewhere for many, many users. Doh, what a crazy idea! Some other body should take the first somebody out somewhere and put them out of their misery. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/10/2013 16:24, Greg Freemyer a écrit :
find /usr -type f -links +200 -print0 | xargs -0 ls -l | more
On my 12.3 system, I have 518 files output by that. They are all in /usr/lib/locale.
*sub dirs of locale* -rw-r--r-- 268 root root 23 18 sept. 16:17 /usr/lib/locale/ug_CN/LC_MEASUREMENT -rw-r--r-- 268 root root 23 18 sept. 16:17 /usr/lib/locale/uk_UA.utf8/LC_MEASUREMENT jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
No, nor in 12.3. There are RPMs that won't even install if the destination is btrfs. The issue is limited links (hard? / soft?).
Interesting. I haven't heard of that problem before. Is it this one: http://nlug.ml1.co.uk/2012/05/btrfs-max-number-of-hardlinks-gotcha/3127 that was apparently fixed last December: https://btrfs.wiki.kernel.org/index.php/Changelog -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth said the following on 10/02/2013 09:41 AM:
Greg Freemyer wrote:
No, nor in 12.3. There are RPMs that won't even install if the destination is btrfs. The issue is limited links (hard? / soft?).
Interesting. I haven't heard of that problem before. Is it this one:
http://nlug.ml1.co.uk/2012/05/btrfs-max-number-of-hardlinks-gotcha/3127
Eh? <quote> You are very limited to the maximum number of hard links to a single file when the hard links and that one target file are all in the same directory. For hard links where the source and target are in different directories, the limit for btrfs is a more reasonable 2^32. </quote> That's for one file. NOT the total number of links the file system supports. IF and ONLY IF you have an old version AND you have long file names AND you link to the same file in the same directory with more and more of those long file names THEN ....... Fringe case? I'd say that there's something peculiar aout the design of your software if its doing that. Cam MS-Windows do that? -- 'Witches just aren't like that,' said Magrat. 'We live in harmony with the great cycles of Nature, and do no harm to anyone, and it's wicked of them to say we don't. We ought to fill their bones with hot lead.' (Wyrd Sisters) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 01 Oct 2013, Duaine Hechler wrote:
And, with ext3, even with journalling, I would ocassinally loose files.
How? If the file occupies one sector (512 Bytes) on one disk and that craps out under you, that file is LOST! The point now is, how does the FS handle that situation. And I've made the bad experience, that reiserfs craps it's pants in that situation. ext2/3/4 justs shrugs, tells you "that sector is unreadable, accept it, what i could recover is in lost+found and get on with it" and fixes anything that needs fixing and you recover the rest if the file was larger than just one sector. And I use ext3 now (except for the SSD with ext4 and the mentioned newsspool-image) exclusively for tons of files (even locally that's ~14TB, not counting several external drives and the "file-server" with another 10TB or so (7+1 IDE + SSD drive locally, 8+1 IDE on the file-server, several external drives)... .). Oh, I did once lose about 400G-1T files on two 400G (or 500G? Been a while) drives using ext3. But that was because the drives failed. Nothing ANY filesystem could have done about it. The second drive didn't even register in the BIOS anymore (nor the linux kernel on boot, 'twas just dead)... IIRC I could scrape some stuff off the first failed drive. But, again, nothing to do with the FS whatsoever!
Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files.
ext3! With vehemence regarding the implementation and a lot of experience too.
Now, (12.2), is btrfs ?
Partly stable. Still evolving very rapidly. SUSE chose a subset for SLES to support that seems stable enough, but I'd stay with ext3 anyway (or ext4 for SSDs). Actually, ext4 should be by now stable enough for everyday use. -dnh -- Truth's a bitch. -- Beka Valentine, Andromeda 3x04 - "Cui Bono" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/02/2013 05:22 AM, David Haller wrote:
Hello,
On Tue, 01 Oct 2013, Duaine Hechler wrote:
And, with ext3, even with journalling, I would ocassinally loose files. How? If the file occupies one sector (512 Bytes) on one disk and that craps out under you, that file is LOST! The point now is, how does the FS handle that situation. And I've made the bad experience, that reiserfs craps it's pants in that situation. ext2/3/4 justs shrugs, tells you "that sector is unreadable, accept it, what i could recover is in lost+found and get on with it" and fixes anything that needs fixing and you recover the rest if the file was larger than just one sector.
And I use ext3 now (except for the SSD with ext4 and the mentioned newsspool-image) exclusively for tons of files (even locally that's ~14TB, not counting several external drives and the "file-server" with another 10TB or so (7+1 IDE + SSD drive locally, 8+1 IDE on the file-server, several external drives)... .).
Oh, I did once lose about 400G-1T files on two 400G (or 500G? Been a while) drives using ext3. But that was because the drives failed. Nothing ANY filesystem could have done about it. The second drive didn't even register in the BIOS anymore (nor the linux kernel on boot, 'twas just dead)... IIRC I could scrape some stuff off the first failed drive. But, again, nothing to do with the FS whatsoever!
Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files. ext3! With vehemence regarding the implementation and a lot of experience too.
Now, (12.2), is btrfs ? Partly stable. Still evolving very rapidly. SUSE chose a subset for SLES to support that seems stable enough, but I'd stay with ext3 anyway (or ext4 for SSDs).
Actually, ext4 should be by now stable enough for everyday use.
-dnh Trolling ? not me - just trying to make the best decision on what to migrate to.
- - Reisferfs - for 4+ years - NO files lost - - ext3fs - before that - several files lost (even with journalling) - - btrfs - seems to be great - except for file receovery So bottom line, I guess my question is - what is the best fs + the best file recovery fs ? Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans. You're trolling. -- This e-mail is confidential and privileged. That's right, confidential. Even though I sent it to a mailing list, it's still confidential. Not only is *it* privileged, but so are you, you lucky user, since you've gotten a message from *me*! If you are not the intended recipient please accept our apologies. On second thought, why are we apologizing? You've accepted the message. If you aren't the intended recipient, what are you, some kind of spy?!? Please do not disclose, copy or distribute information in this e-mail. [Sigh.] You've already copied it, haven't you? You downloaded it from the server, so you copied it onto your machine. Then your mailer made another copy in memory, just to display it to you. Don't do it anymore, alright? Don't take any action in reliance of on its contents: to do so is strictly prohibited and may be unlawful. It's also ungrammatical: if anyone ever figures out what that previous sentence meant, please let us know. Please inform us that this message has gone astray before deleting it. What can you do? You try to bring email up right, and the next thing you know they're hanging out on IRC and trying out NetBEUI. Thank you for your co-operation. Actually we just added that last bit to pad out the message and keep you reading for the few more seconds it will take our crack anti-cracker team (get it? Never mind.) to get to your location and terminate your machine with extreme prejudice. You have been warned. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives. Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive) Is this what you are looking for, to give me a better answer ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/03/2013 02:04 PM, Duaine Hechler wrote:
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives.
Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive)
Is this what you are looking for, to give me a better answer ?
Well ............. I bit the bullet and converted to ext4 ! -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/10/13 13:13, Duaine Hechler wrote:
On 10/03/2013 02:04 PM, Duaine Hechler wrote:
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives.
Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive)
Is this what you are looking for, to give me a better answer ?
Well ............. I bit the bullet and converted to ext4 !
Is that why I felt the earth move? :-) BC -- Using openSUSE 13.1, KDE 4.11.2 & kernel 3.11.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/04/2013 10:17 PM, Basil Chupin wrote:
On 05/10/13 13:13, Duaine Hechler wrote:
On 10/03/2013 02:04 PM, Duaine Hechler wrote:
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives.
Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive)
Is this what you are looking for, to give me a better answer ?
Well ............. I bit the bullet and converted to ext4 !
Is that why I felt the earth move? :-)
BC
Maybe .... Is there a reason I keep seeing disk activity when I'm doing nothing - related to ext4 journaling ? -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/10/13 17:12, Duaine Hechler wrote:
On 10/04/2013 10:17 PM, Basil Chupin wrote:
On 05/10/13 13:13, Duaine Hechler wrote:
On 10/03/2013 02:04 PM, Duaine Hechler wrote:
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives.
Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive)
Is this what you are looking for, to give me a better answer ?
Well ............. I bit the bullet and converted to ext4 !
Is that why I felt the earth move? :-)
BC
Maybe .... Is there a reason I keep seeing disk activity when I'm doing nothing - related to ext4 journaling ?
I am not sure. I remember that I had this "trouble" some years ago and after raising the question here about this managed to trace the "problem" to some process which kept checking to see if there was data waiting to be written to disk. But this was when I was using ext3 (or even possibly Reiserfs - can't remember which). I have been using ext4 for years now and don't see this. One thing you could try is to run e2fsck MANUALLY and *without* using the auto fix option ( -p ) and see if the file system is 'clean'. (I know that fsck is run at every boot but it doesn't do a full check - I learnt this from experience.) To run e2fsck, boot into level #1 then as root: mount -o remount,ro /dev/sdaXX where sdaXX is the / partition and answer the questions - if they appear; if they do appear then let e2fsck do the repairs. I normally remount sdaXX with: mount - remount,rw /dev/sdaXX and then rebooting. Have a look at the man e2fsck to get info re e2fsck if you want to know more. BC -- Using openSUSE 13.1, KDE 4.11.2 & kernel 3.11.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/05/2013 05:56 AM, Basil Chupin wrote:
On 05/10/13 17:12, Duaine Hechler wrote:
On 10/04/2013 10:17 PM, Basil Chupin wrote:
On 05/10/13 13:13, Duaine Hechler wrote:
On 10/03/2013 02:04 PM, Duaine Hechler wrote:
On 10/03/2013 07:02 AM, Anton Aylward wrote:
Duaine Hechler said the following on 10/03/2013 01:28 AM:
> So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
Without defining context, "best" is meaningless. What's good for you may not be good for me. Context is everything. Carving on tablets of stone is an adequate response to the way you've posed your question and was good enough for the Greeks and Romans.
You're trolling.
Trolling ........... well ........... if you would drop your eyes down to my sig line - you would see the main context of my drives.
Self employed, small business owner (accounting (Quasar), Firefox, Thunderbird)) (+ household entertainment file server (movies, mp3s, etc) + printer sharing server) (Running from Primary drive and Secondary drive as backup using rsync) (Third small drive with VB running Win 7 - data files being shared to Linux Primary drive)
Is this what you are looking for, to give me a better answer ?
Well ............. I bit the bullet and converted to ext4 !
Is that why I felt the earth move? :-)
BC
Maybe .... Is there a reason I keep seeing disk activity when I'm doing nothing - related to ext4 journaling ?
I am not sure. I remember that I had this "trouble" some years ago and after raising the question here about this managed to trace the "problem" to some process which kept checking to see if there was data waiting to be written to disk. But this was when I was using ext3 (or even possibly Reiserfs - can't remember which). I have been using ext4 for years now and don't see this.
One thing you could try is to run e2fsck MANUALLY and *without* using the auto fix option ( -p ) and see if the file system is 'clean'. (I know that fsck is run at every boot but it doesn't do a full check - I learnt this from experience.) To run e2fsck, boot into level #1 then as root:
mount -o remount,ro /dev/sdaXX
where sdaXX is the / partition and answer the questions - if they appear; if they do appear then let e2fsck do the repairs.
I normally remount sdaXX with:
mount - remount,rw /dev/sdaXX
and then rebooting.
Have a look at the man e2fsck to get info re e2fsck if you want to know more.
BC
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/13 04:19, Duaine Hechler wrote:
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up
Do a search on "jdb2" :-) . BC -- Using openSUSE 13.1, KDE 4.11.2 & kernel 3.11.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/06/2013 01:48 AM, Basil Chupin wrote:
On 06/10/13 04:19, Duaine Hechler wrote:
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up
Do a search on "jdb2" :-) .
BC
Never mind - I'm dumping ext4 for now !!!!! Going back to reiserfs for now !!!!! -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/13 20:50, Duaine Hechler wrote:
On 10/06/2013 01:48 AM, Basil Chupin wrote:
On 06/10/13 04:19, Duaine Hechler wrote:
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up
Do a search on "jdb2" :-) .
BC
Never mind - I'm dumping ext4 for now !!!!!
Going back to reiserfs for now !!!!!
Your choice, but as you were told Reiserfs is not going anywhere. I've been using ext4 for years and only had a hassle the one time when we had a lightning strike nearby and we lost power while data was being written to the HDD. Which is why I had to run e2fsck as I already explained. BC -- Using openSUSE 13.1, KDE 4.11.2 & kernel 3.11.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel Corsair "Vengeance" RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX550Ti 1GB DDR5 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/06/2013 05:07 AM, Basil Chupin wrote:
On 06/10/13 20:50, Duaine Hechler wrote:
On 10/06/2013 01:48 AM, Basil Chupin wrote:
On 06/10/13 04:19, Duaine Hechler wrote:
After looking at - iotop - every second of two - I see - jdb2/xxxx pop up
Do a search on "jdb2" :-) .
BC
Never mind - I'm dumping ext4 for now !!!!!
Going back to reiserfs for now !!!!!
Your choice, but as you were told Reiserfs is not going anywhere.
I've been using ext4 for years and only had a hassle the one time when we had a lightning strike nearby and we lost power while data was being written to the HDD. Which is why I had to run e2fsck as I already explained.
BC
Well ..... I trying, what I think, is the best of both worlds - running my primary /home with btrfs - and my backup with reiserfs. I wouldn't mind trying ext4 - except for the constant journal updating with jbd2 <sigh> Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Just because Reiserfs isn't "going anywhere" is no reason not to use it. I don't want my file system to "go anywhere" I just want it to be rock solid and reliable. So I think you've made a sound decision. You are familiar with it and it works for you. I've used it on my server for almost a decade. Duaine Hechler <dahechler@att.net> wrote:
On 06/10/13 20:50, Duaine Hechler wrote:
On 10/06/2013 01:48 AM, Basil Chupin wrote:
On 06/10/13 04:19, Duaine Hechler wrote:
After looking at - iotop - every second of two - I see - jdb2/xxxx
On 10/06/2013 05:07 AM, Basil Chupin wrote: pop up
Do a search on "jdb2" :-) .
BC
Never mind - I'm dumping ext4 for now !!!!!
Going back to reiserfs for now !!!!!
Your choice, but as you were told Reiserfs is not going anywhere.
I've been using ext4 for years and only had a hassle the one time when we had a lightning strike nearby and we lost power while data was being written to the HDD. Which is why I had to run e2fsck as I already explained.
BC
Well ..... I trying, what I think, is the best of both worlds - running my primary /home with btrfs - and my backup with reiserfs.
I wouldn't mind trying ext4 - except for the constant journal updating with jbd2 <sigh>
Duaine
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 03 Oct 2013, Duaine Hechler wrote:
On 10/02/2013 05:22 AM, David Haller wrote:
On Tue, 01 Oct 2013, Duaine Hechler wrote:
And, with ext3, even with journalling, I would ocassinally loose files. How? ^^^???
[..]
And I use ext3 now (except for the SSD with ext4 [..]
Now, that I've doubled my drive space, what is the best - supported - filesystem - that will be the best at NOT losing files. ext3! With vehemence regarding the implementation and a lot of experience too.
Now, (12.2), is btrfs ? Partly stable. Still evolving very rapidly. SUSE chose a subset for SLES to support that seems stable enough, but I'd stay with ext3 anyway (or ext4 for SSDs).
Actually, ext4 should be by now stable enough for everyday use.
Trolling ? not me - just trying to make the best decision on what to migrate to.
Where have I written anything about you trolling?
- - Reisferfs - for 4+ years - NO files lost
- - ext3fs - before that - several files lost (even with journalling)
See above: HOW did you lose files on ext3?
So bottom line, I guess my question is - what is the best fs + the best file recovery fs ?
See above. I've already answered that. -dnh -- Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .. :w :q :wq :wq! ^d X^? exit X Q ^C ^c ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d man help ^C exit ?Quit ?q CtrlShftDel "Hey, what does this button d..." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-10-01 a las 22:51 -0500, Duaine Hechler escribió:
Ok, when I decided on the use of the Resiserfs, I needed the absolute max use of the drive.
Consider that when reiserfs was designed disk space was smaller. One problem with it is that it doesn't scale well to large filesystems, or several filesystems (one thread only). I love reiserfs, but it has its limits. Don't use it for the entire space, use it only on smaller spaces with usage types where it shines - like for instance the news pool, with millions of inodes and small files. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlJRYkgACgkQja8UbcUWM1xVdwD8CZdP7ZrfXPkKQ/+8u3tyuwXL OhFQsG1IQ2/XXED2dqEA/imGrCpebzFRIVEMsHNtUfRI7Yd8mgDdysUnQ0I68KpH =sxZl -----END PGP SIGNATURE-----
Carlos E. R. said the following on 10/06/2013 09:14 AM:
El 2013-10-01 a las 22:51 -0500, Duaine Hechler escribió:
Ok, when I decided on the use of the Resiserfs, I needed the absolute max use of the drive.
Consider that when reiserfs was designed disk space was smaller. One problem with it is that it doesn't scale well to large filesystems, or several filesystems (one thread only). I love reiserfs, but it has its limits. Don't use it for the entire space, use it only on smaller spaces with usage types where it shines - like for instance the news pool, with millions of inodes and small files.
As Carlos says, in the right context ReiserFS is solid and a great file system. I use it with small(er) file systems such as my collection of PDFs, mail on my mail server (maildir AND the hundred of smaller mbox) and a few other places such as my Ruby development partition. Using ReiserFS with LVM on a larger disk so as to break the partitions down into a more manageable size (I use 5G partitions so I can 'mirror' backup them to a DVD via a snapshot) works very well. I don't know what Carlos means about 'thread' -- I use ReiserFS on a NFS server - the PDFs & Ruby partitions I mentioned - and have no problems with it. Perhaps Carlos can expand on what he means. ReiserFS also makes mirroring very easy :-) The criticism that its not seen much revision is a bit gratuitous; compare with, for example, Microsoft's Internet Explorer which was broken-by-design and needs constant fixing, or Firefox which is accumulating eye-candy. ReiserFS was and is a good, robust design. What is interesting is that while UNIX was the stripped down version of Multics, BtrFS seems to be a version of the ReiserFS with all the bells and whistles - Multics/UNIX in reverse. What Brooks called "The Second System Effect". I'm happy playing with BtrFS on my desktop but I use ReiserFS for the stuff I absolutely don't want to loose. I've found it more reliable than ext3FS. -- 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 2013-10-06 15:38, Anton Aylward wrote:
I don't know what Carlos means about 'thread' -- I use ReiserFS on a NFS server - the PDFs & Ruby partitions I mentioned - and have no problems with it.
That the code is single threaded, ie, it runs in a single cpu core, even if you have 12 available and several partitions. Thus it scales badly. This is probably something they wanted to develop more when the catastrophe happened to their leadership... to say it politely. I really hope to see the next version (3? 4?) implemented, distributed, some time. - -- Cheers / Saludos, Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJR2AsACgkQja8UbcUWM1wVkgD/fpUAEeUM0P89iZ8Qincr+wQb 923I1818/6DxY7qeKpUA/i1fqiPBzXoR5Eg+SEVW9g34ka6Va93Qa0ypfHf7Ik02 =id/7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sun, 06 Oct 2013, Carlos E. R. wrote:
I really hope to see the next version (3? 4?) implemented, distributed, some time.
It is. http://en.wikipedia.org/wiki/Reiser4#Future_of_Reiser4 But ... See e.g. http://sourceforge.net/p/reiser4/code/ref/master/ http://sourceforge.net/projects/reiser4/files/reiser4-for-linux-3.x/ -dnh -- Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. -- RFC 1391 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/6/2013 6:14 AM, Carlos E. R. wrote:
Consider that when reiserfs was designed disk space was smaller. One problem with it is that it doesn't scale well to large filesystems,
Define Large. I've got raided 800(ish) gig Reiser drives in a couple servers. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/06/2013 02:13 PM, John Andersen wrote:
On 10/6/2013 6:14 AM, Carlos E. R. wrote:
Consider that when reiserfs was designed disk space was smaller. One problem with it is that it doesn't scale well to large filesystems, Define Large.
I've got raided 800(ish) gig Reiser drives in a couple servers.
800-GB is kind of small. I tried Reiserfs on a 18-TB partition recently, it didn't work. Apparently 16-TB is the max. Btrfs didn't work either due to a known bug. My old standby XFS has worked well up to 72-TB, as long as you don't have to use any Adobe software on it. Regards, Lew -- 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 2013-10-06 23:25, Lew Wolfgang wrote:
On 10/06/2013 02:13 PM, John Andersen wrote:
On 10/6/2013 6:14 AM, Carlos E. R. wrote:
800-GB is kind of small. I tried Reiserfs on a 18-TB partition recently, it didn't work.
Not working is not what I had in mind... rather that the speed came down with large sizes and large loads. I understand the code is single threaded, ie, one cpu core only. I don't have figures, unfortunately. I'd like to see them. - -- Cheers / Saludos, Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJR1vQACgkQja8UbcUWM1z4CAD9FdLvlnSTfKZZkTqdI834L4eY U8iEoFyO8q2Q9E3Lfo4A/Auw6192bBleTM2kfmd5NtiI7ngVN4h/raQ1o1wgD/+L =GYtU -----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 2013-10-06 23:13, John Andersen wrote:
On 10/6/2013 6:14 AM, Carlos E. R. wrote:
Consider that when reiserfs was designed disk space was smaller. One problem with it is that it doesn't scale well to large filesystems,
Define Large.
Good question.
I've got raided 800(ish) gig Reiser drives in a couple servers.
You would have to ask someone with experience in reiserfs code. This is what they said years ago. If you have a disk with 2 TB, you could test it. Format and use it at various sizes and loads, and see how it performs, and compare. - -- Cheers / Saludos, Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlJR1iwACgkQja8UbcUWM1wwfwD/RIq87kQolmUg5yw/Sqs8TU4z aIQCoRFJ2qwYelkuV6kA/jwcBD7B3TW6wjf5C83yZiKvojx8gn0A0jVhDgh4YDnZ =6PC1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Sep 29, 2013 at 11:49 PM, Duaine Hechler <dahechler@att.net> wrote:
I am upgrading from 500GB to 1TB drives. The 500GB drives are 99% full.
After I do the initial upgrade, how is the data spread across the drive ?
Contiguous from front to back like Windows FS ? Or evenly spread (but contiguously) across the drive ?
Ultimately, I'm trying to figure out - is the front of the drive going to get the brunt of the work or is the data going to be scattered across the drive.
General layout: root (/) swap /home (rest of drive)
TIA, Duaine
Duaine, You know what's in partitions, so I assume you are asking how the data is stored inside the individual filesystems. You need to say what filesystem you're using, but for XFS as an example it is optimized for placement on RAID, therefore it spreads the data out as much as it can in hopes that the data ends up split across lots of spindles and therefor the parallel nature of raid gets full benefit. A filesystem optimized for a single drive will keep all the data closely packed in an effort to minimize disk seek time. Thus many linux desktop filesystems will keep data closely packed in an effort to reduce the distance the head has to move to go from one piece of data to the next. Also the outer edge of the drive spins at a faster inches / second rate, so filesystems use low numbered sectors in preference to high number sectors in hopes that the low numbered sectors will be closer to the outer edge. ie. if the RPMs are constant then a 1.5 inch radius circle has a linear speed 3x faster than a 0.5 inch radius circle. As to the "brunt" of the work, the disk head flies over the top of the platter, so there is in theory no wear and tear on the platter as data is read/written. It was an issue with 2005 era flash disk that did not wear-level, but with current generation rotating disks and SSDs there is no wear and tear advantage I know of to spreading the workload around the disk. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/30/2013 07:08 AM, Greg Freemyer wrote:
You need to say what filesystem you're using, but for XFS as an example it is optimized for placement on RAID, therefore it spreads the data out as much as it can in hopes that the data ends up split across lots of spindles and therefor the parallel nature of raid gets full benefit.
That makes no sense what so ever. Raid doesn't work that way. Everything is mirrored or everything is spread across spindles depening on which raid you choose. And as a general comment on this thread, people need to stop thinking about micromanaging how data is stored on drives and let the OS and the FS do its job. Virtually any File system will do a better job of this than any fiddling by the user. Unless you have large static files, it only matters on initial disk loading anyway, because that is the last time you will be able to influence location of a file on the disk. Virtually ANY Linux file system won't need defraging, ever. -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Sep 30, 2013 at 1:38 PM, John Andersen <jsamyth@gmail.com> wrote:
On 09/30/2013 07:08 AM, Greg Freemyer wrote:
You need to say what filesystem you're using, but for XFS as an example it is optimized for placement on RAID, therefore it spreads the data out as much as it can in hopes that the data ends up split across lots of spindles and therefor the parallel nature of raid gets full benefit.
That makes no sense what so ever. Raid doesn't work that way. Everything is mirrored or everything is spread across spindles depening on which raid you choose.
I may have slightly misspoke, but it is more or less how the developers describe it. Or from: <http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf> === Allocation Groups XFS filesystems are divided into a number of equally sized chunks called Allocation Groups. Each AG can almost be thought of as an individual filesystem that maintains it's own space usage. Each AG can be up to one terabyte in size (512 bytes * 2^31), regardless of the underlying device's sector size. Each AG has the following characteristics: • A super block describing overall filesystem info • Free space management • Inode allocation and tracking Having multiple AGs allows XFS to handle most operations in parallel without degrading performance as the number of concurrent accessing increases. === Thus you can see that XFS has an interleaved structure of superblocks, inodes and data blocks. When files are written they tend to get spread out across the disk to keep the AGs at similar levels of utilization. If you have a single 2 TB filesystem, I don't know how many AGs get created, but clearly at least 2. In a raid setup with multiple spindles, having multiple AGs is a performance boost. Of course you need to have the AGs laid out so they are on different drives. For that reason, XFS uses the RAID geometry during mkfs time to lay itself out for best performance. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Sep 30, 2013 at 1:58 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Of course you need to have the AGs laid out so they are on different drives.
I meant the AGs metadata (ie. superblock, etc.) Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (14)
-
Andrey Borzenkov -
Anton Aylward -
Basil Chupin -
Carlos E. R. -
Dave Howorth -
David Haller -
Duaine Hechler -
Felix Miata -
Greg Freemyer -
James Knott -
jdd -
John Andersen -
Lew Wolfgang -
Tom Wekell