From: Tomasz Chmielewski <mangoo@wpkg.org>
To: markgw@sgi.com
Cc: xfs@oss.sgi.com
Subject: Re: is xfs good if I have millions of files and thousands of hardlinks?
Date: Wed, 20 Feb 2008 10:56:07 +0100 [thread overview]
Message-ID: <47BBF937.2020104@wpkg.org> (raw)
In-Reply-To: <47BB5873.6040703@sgi.com>
Peter Grandi wrote:
> mangoo> In general, because new files and hardlinks are being
> mangoo> added all the time and the old ones are being removed,
> mangoo> this leads to a very, very poor performance.
>
> That is not the cause of the poor performance. The ultimate
> cause is rather different.
Well, adding new files and hardlinks all the time leads to that that the
inodes are scattered all over the disk.
> mangoo> When I want to remove a lot of directories/files (which
> mangoo> will be hardlinks, mostly), I see disk write speed is
> mangoo> down to 50 kB/s - 200 kB/s (fifty - two hundred
> mangoo> kilobytes/s) - this is the "bandwidth" used during the
> mangoo> deletion.
>
> How is bandwidth relevant for that? OK that there are quotes,
> but it seems very very stranget regardless.
The filesystem is available via iSCSI, so it's easy to measure the
current performance. But iSCSI is not a problem here - performance is
very good on an empty filesystem on that very same iSCSI/SAN device.
What I mean, is that when I remove large amount of files, the bandwidth
used for writing to the disk is only down to 50-200 kB/s. Down from
what, one might ask? Let me paste here yet another quotation from
linux-fsdevel list, it may shed some more light:
Recently I began removing some of unneeded files (or hardlinks) and
to my surprise, it takes longer than I initially expected.
After cache is emptied (echo 3 > /proc/sys/vm/drop_caches) I can
usually remove about 50000-200000 files with moderate performance.
I see up to 5000 kB read/write from/to the disk, wa reported by top
is usually 20-70%.
After that, waiting for IO grows to 99%, and disk write speed is down
to 50 kB/s - 200 kB/s (fifty - two hundred kilobytes/s).
> mangoo> Also, the filesystem is very fragmented ("dd
> mangoo> if=/dev/zero of=some_file bs=64k" writes only about 1
> mangoo> MB/s).
>
> Then more the merrier.
Umm, no.
Usually, one is merrier when these numbers are high, not low ;)
> mangoo> Will xfs handle a large number of files, including lots
> mangoo> of hardlinks, any better than ext3?
>
> It shows consideration to consult the archives of a mailing list
> before aking a question. It may be a good idea to do it even
> after posting a question :-).
Oh, I did consult the archive. There are not many posts about hardlinks
here on this xfs list (or, at least I didn't find many).
There was even a similar subject last year: someone had a 17 TB array
used for backup, which was getting full, and asked if xfs is or will be
capable of transparent compression.
As xfs will not have transparent compression in a foreseeable future, it
was suggested to him that he should use hardlinks - that alone could
save him lots of space.
I wonder if the guy uses hardlinks now, and if yes, how does it behave
on this 17 TB array (my filesystem is just 1.2 TB, but soon, I'm about
to create a bigger one on another device - and hence my questions).
--
Tomasz Chmielewski
http://wpkg.org
prev parent reply other threads:[~2008-02-20 9:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 13:53 is xfs good if I have millions of files and thousands of hardlinks? Tomasz Chmielewski
2008-02-19 21:09 ` Peter Grandi
2008-02-19 22:30 ` Mark Goodwin
2008-02-19 22:43 ` Tomasz Chmielewski
2008-02-20 9:56 ` Tomasz Chmielewski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47BBF937.2020104@wpkg.org \
--to=mangoo@wpkg.org \
--cc=markgw@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox