From: Eric Sandeen <sandeen@sandeen.net>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Sandon Van Ness <sandon@van-ness.com>,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
Alan Piszcz <ap@solarrain.com>
Subject: Re: Is EXT4 the right FS for > 16TB?
Date: Sun, 19 Dec 2010 11:01:23 -0600 [thread overview]
Message-ID: <4D0E3A63.606@sandeen.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1012191151570.28865@p34.internal.lan>
On 12/19/10 10:53 AM, Justin Piszcz wrote:
> Hi,
>
> Wow, there were no updates though after Eric's last comment..
> Eric, have there been any improvements in the past 6 months?
>
> Or should one still steer clear from EXT4 > 16TB?
There is still no released e2fsprogs which supports > 16T for
ext4, but testing of the not-released bits is welcomed...
Ted says a 16T-capable version is coming soon. There's still
work to be done there, though.
-Eric
> Justin.
>
> On Sun, 19 Dec 2010, Sandon Van Ness wrote:
>
>> Was it me (houkouonchi) on hard forum? I asked if > 16 TiB support was
>> considered stable on here a while back:
>>
>> Is >16TB support considered stable?
>>
>> This was 6 months ago so maybe things have changed. The thread:
>>
>> http://kerneltrap.org/mailarchive/linux-ext4/2010/5/28/6884603/thread
>>
>> Luckily JFS fixed there userland utilities bug of not being able to
>> handle > 32TiB very shortly after this and I ended up going that route
>> and I have yet to have any data loss or problems on my JFS volume:
>>
>> root@dekabutsu: 08:32 AM :~# df -H /data
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sdd1 36T 22T 15T 61% /data
>> root@dekabutsu: 08:32 AM :~#
>>
>> At work with our hundreds/thousands of servers we will likely be going
>> ext4 as we wont be using it on >16 TiB. I think its a huge improvement
>> over ext3 but for my use JFS ended up being a better fit. I
>> refuse/refused to go XFS.
>>
>> On 12/19/2010 03:52 AM, Justin Piszcz wrote:
>>> Hi,
>>>
>>> I've read a lot of posts regarding people who setup RAID volumes of
>>> and up to around 16TB and EXT4 is typically used.
>>>
>>> However, in various forums, people still ask what is the correct
>>> filesystem for > 16TB? I did read one post somewhere that stated the
>>> ext4 developers did not recommend using ext4 for very large volumes,
>>> is this still true?
>>>
>>> I am looking at creating a 43TB volume possibly in the near future and
>>> I have used XFS in the past, which works well and would probably not
>>> have any problem with it; however, I have bitten quite a number of
>>> times by XFS bugs in the past several years, so I was curious, how
>>> does EXT4 perform on larger volumes, e.g., 20TB?
>>>
>>> Are there any caveats / problems?
>>>
>>> Justin.
next prev parent reply other threads:[~2010-12-19 17:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-19 11:52 Is EXT4 the right FS for > 16TB? Justin Piszcz
2010-12-19 16:35 ` Sandon Van Ness
2010-12-19 16:53 ` Justin Piszcz
2010-12-19 17:01 ` Eric Sandeen [this message]
2010-12-19 17:14 ` Ric Wheeler
2010-12-19 19:14 ` Justin Piszcz
2010-12-19 19:30 ` Eric Sandeen
2010-12-19 22:21 ` Ric Wheeler
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=4D0E3A63.606@sandeen.net \
--to=sandeen@sandeen.net \
--cc=ap@solarrain.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandon@van-ness.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.