On 02/27/2014 02:54 PM, Roman Bysh wrote:

On 02/27/2014 03:34 PM, Greg Freemyer wrote:

...

I don't know if anyone cares, but I was surprised to see:

http://oss.sgi.com/pipermail/xfs/2014-February/034582.html

It looks like early phase exploration on the one hand, but on the other hand Red Hat Beta 7 is already using XFS as the default filesystem:

http://www.internetnews.com/ent-news/red-hat-enterprise-linux-7-beta-uses-xf...

Greg -- Greg Freemyer

Interesting. It makes sense to use XFS if you are dealing with high volume data.

That matches my understanding. For example, the MythTV project recommends using XFS for its video files. In particular, its performance when deleting multi-GB files is much better than ext4. With the latter, they have to throttle back the delete so as not to consume all of the CPU. I have a couple of kernel sources on XFS volumes, and the kernel builds sometimes pause. I suspect that XFS is not so good with small files. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Feb 27, 2014 at 5:05 PM, Yamaban wrote:

On Thu, 27 Feb 2014 22:50, Larry Finger wrote:

...

On 02/27/2014 02:54 PM, Roman Bysh wrote:

...

On 02/27/2014 03:34 PM, Greg Freemyer wrote:

...

I don't know if anyone cares, but I was surprised to see:

http://oss.sgi.com/pipermail/xfs/2014-February/034582.html

It looks like early phase exploration on the one hand, but on the other hand Red Hat Beta 7 is already using XFS as the default filesystem:

http://www.internetnews.com/ent-news/red-hat-enterprise-linux-7-beta-uses-xf...

Greg -- Greg Freemyer

Interesting. It makes sense to use XFS if you are dealing with high volume data.

That matches my understanding. For example, the MythTV project recommends using XFS for its video files. In particular, its performance when deleting multi-GB files is much better than ext4. With the latter, they have to throttle back the delete so as not to consume all of the CPU. I have a couple of kernel sources on XFS volumes, and the kernel builds sometimes pause. I suspect that XFS is not so good with small files.

I see the same, 13.1 + XFS is very good for file-sizes above 10MB, a few smaller ones do not hurt much, but XFS for rootfs (/)? - No, not ideal.

I did not have the time to test for file-sizes between 500 kB and 10 MB.

For me the best ever fs for small files and may directories (e.g. mail/news/static file servers[ftp/http]) in matters of speed (access+create+remove+change) and space-efficiency was and still is reiserfs (3.6), but btrfs still gets better, so we will see.

- Yamaban.

A couple years ago XFS got massive speed improvements for small files (ie. an order of magnitude faster comparing a 2012 kernel to a 2010 kernel). They rolled in over several kernel releases, but the 3.3 kernel had most of them in, but it caused other bottlenecks to show up so I think post 3.3 kernels get even faster for the 8-thread plus loads. See http://lwn.net/Articles/476263/ For a single thread perspective, xfs is now merely slow instead of horrible. For 8 threads, in now beats ext4 and btrfs. Or at least it did 2 years ago. Not sure if ext4 or btrfs has been improved since then for multiple thread use. This 2 year old presentation from Dave Chinner is worth watching if you are interesting in the small file handling improvements of XFS from the 2011 timeframe. http://www.youtube.com/watch?v=FegjLbCnoBw If you want to jump straight to the benchmarks with the new algorithm, jump to the 20 minute point. Ar 45 minutes in, Dave Chinner says ext4 should be retired and btrfs and xfs should be the only 2 mainstream kernels. If anyone has a link to newer performance comparisons, I'd like to review them. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/27/2014 07:07 PM, Matthias G. Eckermann wrote:

Hello all,

On 2014-02-27 T 23:05 +0100 Yamaban wrote:

...

On Thu, 27 Feb 2014 22:50, Larry Finger wrote:

...

On 02/27/2014 02:54 PM, Roman Bysh wrote:

...

On 02/27/2014 03:34 PM, Greg Freemyer wrote:

...

...

...

I don't know if anyone cares, but I was surprised to see:

http://oss.sgi.com/pipermail/xfs/2014-February/034582.html

It looks like early phase exploration on the one hand, but

...

on the other hand Red Hat Beta 7 is already using XFS as the default filesystem:

http://www.internetnews.com/ent-news/red-hat-enterprise-linux-7-beta-uses-xf...

Greg -- Greg Freemyer

...

Interesting. It makes sense to use XFS if you are dealing with high volume data.

That matches my understanding. For example, the MythTV project recommends using XFS for its video files. In particular, its performance when deleting multi-GB files is much better than ext4. With the latter, they have to throttle back the delete so as not to consume all of the CPU. I have a couple of kernel sources on XFS volumes, and the kernel builds sometimes pause. I suspect that XFS is not so good with small files.

I see the same, 13.1 + XFS is very good for file-sizes above 10MB, a few smaller ones do not hurt much, but XFS for rootfs (/)? - No, not ideal.

I did not have the time to test for file-sizes between 500 kB and 10 MB.

For me the best ever fs for small files and may directories (e.g. mail/news/static file servers[ftp/http]) in matters of speed (access+create+remove+change) and space-efficiency was and still is reiserfs (3.6), but btrfs still gets better, so we will see.

Apropos filesystems in general and xfs specifically:

xfs is the recommended filesystem for data partitions in SUSE Linux Enterprise for some years already.

xfs also will remain the recommended filesystem for data partitions in the upcoming SUSE Linux Enterprise 12, if not users demand snapshotting, and thus will chose btrfs.

As you know, I assume, SUSE Linux Enterprise 12 will have btrfs as the default for "/", to enable snapshot/rollback right away. Yet if a separate "/home" is configured in the YaST partitioner, it will default to xfs. -- This way we closely follow our own recommendation, don't we?

so long - MgE

P.S.: I personally use btrfs for "/" and "/home", and xfs for the backup storage, ... just in case you were interested.

I think that is a very good recommendation of which I will follow for openSUSE 13.2. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Richard, Am 28.02.2014 10:31, schrieb Richard Biener:

Am I missing something or did I interpret "backup storage" in a wrong way?

Well, even Matthias probably wants to use a proven file system for backup purposes and not some bleeding edge experimental stuff ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 28 February 2014, Matthias G. Eckermann wrote:

Hello Stefan,

On 2014-02-28 T 10:48 +0100 Stefan Seyfried wrote:

...

Well, even Matthias probably wants to use a proven file system for backup purposes and not some bleeding edge experimental stuff ;-)

Why am I not surprised ...

My view: The standard filesystem stuff in btrfs plus the CoW functionality is damn stable, and this includes subvolumes, snapshots, and capabilities built upon.

There is other stuff, not yet mature, and Jeff Mahoney sent a nice table on this list last year where he listed the back-then valid status, see: http://lists.opensuse.org/opensuse-factory/2013-09/msg00029.html The out-of-band deduplication is meanwhile upstream, and - as based on CoW - also stable.

You really should give btrfs a try (again?) ! ;-)

I also think btrfs is the future fs. No need to switch the default for just one or two years until btrfs is stable. So IMO first question is: Would we prefer btrfs or xfs, after btrfs will be stable?". If yes, then don't switch to xfs now. BTW it's just a default. People who know about file systems will use what they prefer anyway. But specially people without much knowledge shouldn't be bothered by changing defaults too often. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Feb 28, 2014 at 9:32 AM, Lew Wolfgang wrote:

On 02/28/2014 05:46 AM, Matthias G. Eckermann wrote:

...

Hello Stefan,

On 2014-02-28 T 10:48 +0100 Stefan Seyfried wrote:

...

Well, even Matthias probably wants to use a proven file system for backup purposes and not some bleeding edge experimental stuff ;-)

Why am I not surprised ...

My view: The standard filesystem stuff in btrfs plus the CoW functionality is damn stable, and this includes subvolumes, snapshots, and capabilities built upon.

There is other stuff, not yet mature, and Jeff Mahoney sent a nice table on this list last year where he listed the back-then valid status, see: http://lists.opensuse.org/opensuse-factory/2013-09/msg00029.html The out-of-band deduplication is meanwhile upstream, and - as based on CoW - also stable.

You really should give btrfs a try (again?) ! ;-)

Does btrfs work on filesystems larger than 15-TB yet? When I tried it last year it was totally unusable.

BTW, I've also been using rdiff-backup for a long time, if anyone's interested.

Regards, Lew

I don't know if this your problem, but 32-bit linux kernel's don't do block devices over 16 TB yet (and may never). The issue is the page cache simply doesn't support it. I happened to read a thread just yesterday that btrfs doesn't have a failsafe to refuse to try (xfs and ext4 simply refuse), so when a 32-bit kernel running btrfs hits roughly 15 TB it starts having some of the data go over 16TB and that in turn fails, potentially in fatal ways. I'm guessing it is a rollover issue and data intended for 16TB + Y, gets written to Y instead. If so, that can be a pretty fatal problem. Here's the thread from yesterday: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg31856.html Obviously, the fix is simple: add a mount check to refuse to mount if a rollover situation is going to happen. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Stefan, On 2014-02-28 T 15:52 +0100 Stefan Seyfried wrote:

Am 28.02.2014 14:46, schrieb Matthias G. Eckermann:

...

You really should give btrfs a try (again?) ! ;-)

There is no again, I never tried it. And I don't intend to in the near future. The reason is simple: I don't need any of its features. XFS fits my feature bill very well (modulo grub compatibility, but that's easily solved with a small ext partition).

OK. That's definitely a valid position.:-)

Once the Idea "snapshots would be neat" crosses my mind (and "performance is no longer prime directive"),

Performance of btrfs is fine, in specific cases even brilliant (many, many small files). One has to be careful in situations where all CoW filesystems suffer:

then I'll certainly try btrfs. Right now my usecases just never involved snapshots, but often involved stuff where btrfs by design cannot win (storing VM images, database, ..., [...]

I am meanwhile also storing VMs and Crypto-Partitions on btrfs, yet certainly using the "NoCOW" flag on that specific file ("chattr +C") to avoid potential negative side effects. Hope that helps. So long - MgE -- Matthias G. Eckermann Senior Product Manager SUSE® Linux Enterprise SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 28 Feb 2014, Matthias G. Eckermann wrote:

Hello Richard and all,

On 2014-02-28 T 10:31 +0100 Richard Biener wrote:

...

On Fri, 28 Feb 2014, Matthias G. Eckermann wrote:

[...]

...

P.S.: I personally use btrfs for "/" and "/home", and xfs for the backup storage, ... just in case you were interested.

And I thought btrfs (or any fs with snapshot capability) would be ideal for backup storage - just create a snapshot before every incremental backup and use rsync. That get's you incremental backups "for free" (compared to do dancing with hardlink trees).

Yes, you have an excellent point here, and actually, I am using this (btrfs snapshots for timeline backup on an external disk) as well for specific kind of data.

For my "/home" I am using it as well, yet with btrfs snapshots on the _local_ disk, using pam_snapper as described here: https://www.suse.com/communities/conversations/menu-du-jour-vivaneau-vert-su... https://www.suse.com/communities/conversations/sieste-siesta/

The backup storage with xfs mentioned above, is what goes to the vault as a "full backup".

An additional argument for this "split" in filesystems: it is good practice, to have the backup on another technology than the original data. That said, here more details about my setup:

Workstation(s): SSD with btrfs for "/" and "/home", and snapshots enabled for both

Full Backup: HDDs (spinning disks) with xfs

And yes, different vendors for SSDs and HDDs. Certainly. No, I am not paranoid:-)

...

[ok, you can also use btrfs remote replication feature but IIRC that's still considered too "beta"]

Indeed, this technology is not mature yet.

...

Am I missing something or did I interpret "backup storage" in a wrong way?

I hope my setup makes sense to you with the additional information and explanation.

It does. I was considering to use btrfs only on the backup media and am currently using ext[34] as main filesystem (I can't tolerate the disk-nearly-full beahvior of btrfs there). It is (should be) much easier to avoid disk-full on the backup disk by simply enabling quota there and dropping old snapshots. That said, something as nice and transparently working as a time capsule + time machine would be really nice to have. zypper search backup doesn't give me a conclusive answer but that I have yast2-backup already installed (whatever that is, no manpage). Richard. -- Richard Biener SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 28.02.2014 13:56, schrieb Matthias G. Eckermann:

On 2014-02-28 T 13:21 +0100 Richard Biener wrote:

...

That said, something as nice and transparently working as a time capsule + time machine would be really nice to have.

You could combine rsync with a snapper configuration for the external disk. Call "snapper create ..." after every rsync run, and you are done. Assuming your external disk has a VolumeLabel as "BienersBtrfsBackup" and would mount to /mounts/BienersBtrfsBackup, you would do:

This actually works without experimental stuff: rdiff-backup handles this on (almost) every filesystem, with proven good mature technologies ;-) You'll even be able to restore your backup using a SLES11GM rescue system if necessary (I'm not actually 100% sure, so I won't claim it works with SLES10, but most likely it will). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Matthias G. Eckermann wrote:

...

to do dancing with hardlink trees).

Yes, you have an excellent point here, and actually, I am using this (btrfs snapshots for timeline backup on an external disk) as well for specific kind of data.

For my "/home" I am using it as well, yet with btrfs snapshots on the _local_ disk, using pam_snapper as described here...

I use snapper.pl xfs volumes & LVM. Not as efficient, but it works for providing "previous versions for my windows client". But basically I have a daily snapper.pl script that does an rsync between yesterday's snap and today's volume -- and puts the diffs in a 3rd vol which is saved as the snapshot. It isn't a substitute for backups, which are done using xfsdump, nightly w/a tower-of-hanoi cycle w/lvl 0's at first of the month. Using thin-provisioned snaps on lvm, one can use any file system and get automatic snapshotting (no rync needed). I haven't seen those on opensuse yet... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Feb 28, 2014 at 1:22 AM, Stefan Seyfried wrote:

Am 27.02.2014 21:34, schrieb Greg Freemyer:

...

I don't know if anyone cares, but I was surprised to see:

http://oss.sgi.com/pipermail/xfs/2014-February/034582.html

It looks like early phase exploration on the one hand, but on the other hand Red Hat Beta 7 is already using XFS as the default filesystem:

http://www.internetnews.com/ent-news/red-hat-enterprise-linux-7-beta-uses-xf...

Why were you surprised?

At least a few openSUSE devs have already said they want the default for the next release to be btrfs. Thus 13.2 might have btrfs as the default FS. I expected Fedora to also transition from ext* to btrfs for default. Having a couple releases with XFS as the default just surprised me as a possibility. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried wrote:

If I had to do a new installation for anything important, I would use XFS for everything but a small (512MB to 1GB) /boot, which would be ext[234], because grub cannot be installed in an XFS partition.

It was my impression that was fixed ~ 2 years ago. I can't say for sure, since I use lilo -- which has no problem with xfs partitions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org