On Fri, Jun 15, 2018 at 07:37:19PM -0700, Elliott Mitchell wrote:
> 
> During the process I ended up running `e2fsck -f` multiple times.  I
> ended up running `e2fsck -f` after enabling each feature (`tune2fs`
> really didn't like enabling multiple features at once).

OK, so I really need a reliable repro to be able to do anything with
this report.

I will note that if you are starting with an ext2/ext3 file system (one
without extents and the uninit_bg or metadata_csum features), you will
get much better performance in the long run if you create a new ext4
file system and then copy all of the data from the ext2 file system to
ext4.

My experience from when we did an ext2 upgrade to ext4 (in no-journal
mode) some six or seven years ago, for our workload, which was for a
cluster file system, was comparing the performance of an existing file
system upgrading to ext4 in place, versus the performance of a freshly
created ext4 file system, was that the upgrade-in-place experience
resulted in roughly half the performance improvement compared to a
fresh ext4 file system.

So if you are going to need to run tune2fs and e2fsck -f multiple
times ---- what are you trying to do?  What's the goal here?

Don't get me wrong; if you can get me a reproducible test case, I'm
happy to look at it.  But Red Hat doesn't support upgrading file
systems via tune2fs.  And that's because there are all sorts of corner
cases and it's very hard to do regression testing or bug
reproductions.  We have used tune2fs to upgrade file systems at
Google, but it's something we testetd extensively, and we only did it
where it makes sense.

> > And do you really need to enable user, group, and project quota
> > tracking?  Please keep in mind there is a performance cost for
> > enabling quota tracking; it is definitely not free....
> 
> I definitely want user quota with journal.  I'm unsure of group and
> project.

For each quota type that you enable, you basically end up paying for
an extra random write, and potentially a random read, associated with
block or inode allocation for a given user or group id, every five
seconds.  So if you don't need group or project tracking, don't turn
it on.  We only track usage based on a group basis, so we only enable
group quotas.

As far as the turning on the quota feature and that terrible error
message --- did the file system have any quota files before, and did
you check to see if the file system was full (e.g., not enough blocks
to allocate the quota file)?

                                                - Ted

Reply via email to