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
