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