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

On Sun, Sep 29, 2013 at 11: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

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 Mon, Sep 30, 2013 at 1:38 PM, John Andersen 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 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

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

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

Duaine Hechler 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 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: 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-----

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

On Wed, Oct 2, 2013 at 9:34 AM, Anton Aylward 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 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

Greg Freemyer said the following on 10/02/2013 04:52 PM:

On Wed, Oct 2, 2013 at 2:14 PM, Anton Aylward 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 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)

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

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

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

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

-----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. 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. 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

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

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

-----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-----

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

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 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

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

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 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

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

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