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