Re: [gentoo-user] Re: MBR partition

[Dale]

Kerin Millar wrote:
> On 07/09/2014 01:28, Dale wrote:
>> Kerin Millar wrote:
>>> On 06/09/2014 13:54, Alan McKinnon wrote:
>>>> On 06/09/2014 14:48, Dale wrote:
>>>>> James wrote:
>>>>>> Joseph <syscon780 <at> gmail.com> writes:
>>>>>>
>>>>>>> Thank you for the information.
>>>>>>> I'll continue on Monday and let you know.  If it will not boot
>>>>>>> with sector
>>>>>> starting at 2048, I will
>>>>>>> re-partition /boot sda1 to start at 63.
>>>>>>
>>>>>> Take some time to research and reflect on your needs (desires?)
>>>>>> about which file system to use. (ext 2,4) is always popular and
>>>>>> safe.
>>>>>> Some are very happy with BTRFS and there are many other interesting
>>>>>> choices (ZFS, XFS, etc etc)......
>>>>>>
>>>>>> There is no best solution; but the EXT family offers tried and
>>>>>> proven
>>>>>> options. YMMV.
>>>>>>
>>>>>>
>>>>>> hth,
>>>>>> James
>>>>>>
>>>>>
>>>>> I'm not sure if it is ZFS or XFS but I seem to recall one of those
>>>>> does
>>>>> not like sudden shutdowns, such as a power failure.  Maybe that has
>>>>> changed since I last tried whichever one it is that has that
>>>>> issue.  If
>>>>> you have a UPS tho, shouldn't be so much of a problem, unless your
>>>>> power
>>>>> supply goes out.
>>>>
>>>> XFS.
>>>>
>>>> It was designed by SGI for their video rendeing workstations back
>>>> in the
>>>> day and used very aggressive caching to get enormous throughput. It
>>>> was
>>>> also brilliant at dealing with directories containing thousands of
>>>> small
>>>> files - not unusual when dealing with video editing.
>>>>
>>>> However, it was also designed for environments where the power is
>>>> guaranteed to never go off (which explains why they decided to go with
>>>> such aggressive caching). If you use it in environments where
>>>> powerouts
>>>> are not guaranteed to not happen, well......
>>>
>>> Well what? It's no less reliable than other filesystems that employ
>>> delayed allocation (any modern filesystem worth of note). Over recent
>>> years, I use both XFS and ext4 extensively in production and have
>>> found the former trumps the latter in reliability.
>>>
>>> While I like them both, I predicate this assertion mainly on some of
>>> the silly bugs that I have seen crop up in the ext4 codebase and the
>>> unedifying commentary that has occasionally ensued. From reading the
>>> XFS list and my own experience, I have formed the opinion that the
>>> maintainers are more stringent in matters of QA and regression testing
>>> and more mature in matters of public debate. I also believe that
>>> regressions in stability are virtually unheard of, whereas regressions
>>> in performance are identified quickly and taken very seriously [1].
>>>
>>> The worst thing I could say about XFS is that it was comparatively
>>> slow until the introduction of delayed logging (an idea taken from
>>> ext3). [2] [3]. Nowadays, it is on a par with ext4 and, in some cases,
>>> scales better. It is also one of the few filesystems besides ZFS that
>>> can dynamically allocate inodes.
>>> <<SNIP>>
>>> --Kerin
>>>
>>> [1]
>>> http://www.percona.com/blog/2012/03/15/ext4-vs-xfs-on-ssd/#comment-903938
>>>
>>> [2]
>>> https://www.kernel.org/doc/Documentation/filesystems/xfs-delayed-logging-design.txt
>>>
>>> [3] https://www.youtube.com/watch?v=FegjLbCnoBw
>>>
>>>
>>
>> The point I was making in my comment was about if the power fails
>> without a proper shutdown.  When I used it a long time ago, it worked
>> fine, until there was a sudden power loss.  That is when problems pop
>> up.  If a person has a UPS, should be good to go.
>
> The point I was making is that there is not a shred of evidence to
> suggest that XFS is any less resilient in this scenario than newer
> filesystems employing delayed allocation such as ext4, btrfs and ZFS.
> What I take issue with is that people continue to single XFS out for
> criticism, regardless. Let XFS be judged as it it stands today, just
> as any other actively developed filesystem should be.
>
> Filesystem implementations are not set in stone. Just as ext4
> developers had to resolve certain engineering challenges raised by the
> use of delayed allocation, so have XFS developers had to do the same
> before them [1].
>
> Arguments generally critical of the use of delayed allocation where
> power loss is a likely event would hold water. Fortunately, options
> remain for such a scenario (ext3, ext4 + nodelalloc).
>
> --Kerin
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7d4fb40
>
>

Which is why I said that the issue could have changed since I last used
that file system.  What I learned is this, every time there was a sudden
power fail, it was unrecoverable.  I ended up reinstalling the OS.  That
is why I posted what I did.   Still, the point is this, if the OP is
going to use the file system that had that issue, research first to make
sure they are prepared for what may still be a side effect or that is is
no longer a problem now.  Every file system there is has something
negative.  It's up to us to find out if that negative can or will apply
to us.  Having the info is better than not having at all.  I wish I knew
that before I tried XFS before. 

I might add, I've had a few sudden power fails on systems with ext4. 
What I have not had yet was a unrecoverable file system like I had with
XFS.  Maybe XFS is improved now but even recently, ext4 didn't seem to
have that issue, at least on the system I was using it on.  I also have
no plans to try XFS again even tho I have a UPS now. 

Now that the OP has info that he/she may not have had before, they can
make a more informed decision. 

Dale

:-)  :-)